Начал работу над пробным проектом Clean Architecture

Просмотров: 3226Комментарии: 0
Технологии

Начал писать код приложения (простой ToDo-менеджер-журнал). Пока что все просто, не знаю, стоит ли что-то пояснять. Описал первые сценарии, вырисовалась структура для Сущностей/Интеракторов/Границ. Предполагается, что на первых порах сценарии будут работать с фиктивными (mock) источниками данных и сервисами. Работу с сессией реализовал в виде сервиса, а не репозитория, поскольку хранение данных текущего пользователя возможно не только в сессии, но и, например, с использованием токенов. Идея сервиса для обработки таких вещей кажется более уместной.

Столкнулся и с первой архитектурной проблемой. Набор задач логично организовать в виде дерева, с иерархией подзадач. Но как отобразить ее в нашей Сущности задачи? С одной стороны, чего проще — ввести дополнительные поля для работы с Nested Sets или Adjacency List. Но эти поля будут отображением реляционной таблицы в нашу Сущность. А Сущность не должна знать о внутреннем устройстве системы хранения данных! Стал копать гуглогруппу о Clean Architecture - и запутался еще больше. Оказывается, Сущность не должна быть отображением нашего объекта данных.

Misconception #1: Entities are data.
Entities are not data. Entities are objects, and objects have functions that implement business rules. Entities may _use_ data; but the _are not_ data. Entities are behavior.

Еще один удар в рушащуюся картину мира нанес следующий пункт

Misconception #2: Entities, Database, and Web use the same data
They most definitely do _not_. Databases store data in strange and arcane formats (like tables) that is inconvenient for most business rule calculations. For that reason we often use ORMs to map the tables into more convenient data structures. Entities use the data from those data structures; but the mapping is not one-to-one. Very often a given entity will use more than one of those data structures. ... The mapping is complex. Moreover, most entities only want certain data elements, and not the entire data structure. So, to keep the entities from knowing too much, it is wise to map the generic data structures that come from the database into entity-specific data structures that keep the entities decoupled from data they don't need.
...
Be very careful. The temptation to use the same data structures (even the same objects) throughout the entire system is strong at first, and can lead you into a coupling nightmare. Keep these tiers separate. Allow the structure of the data in each tier to conform to the needs of _that_ tier.

На этом я пока остановился. Нужно собраться с мыслями и понять, как же должны работать Сущности здорового программиста.

Оставьте комментарий!


Используйте нормальные имена.

     

  

Если вы уже зарегистрированы как комментатор или хотите зарегистрироваться, укажите пароль и свой действующий email. При регистрации на указанный адрес придет письмо с кодом активации и ссылкой на ваш персональный аккаунт, где вы сможете изменить свои данные, включая адрес сайта, ник, описание, контакты и т.д., а также подписку на новые комментарии.

MaxSiteAuth. Войти через loginza

(обязательно)