Мнение автора: на основании своего опыта я выступаю скорее за анемичную модель: когда сущность в основном контейнер для данных, почти не содержащий логику, и наборе команд/сервисов для взаимодействия с ними (и именно на команды ложиться ответственность за сохранение консистентности агрегатов).
Для меня вполне допустим следующий вариант: в доменной логике мы не создаем и не редактируем сущности напрямую, а делаем это через ISetter компонент. В контракт конкретного ISetter мы закладываем способы создания и изменения сущности. В таком случае у нас есть компонент, который указывает на контракт и допустимые способы взаимодействия с конкретной сущностью. Пример поведения, располагаемого в ISetter: 1) типизированные билдеры под конкретные сценарии использования (инварианты), 2) взаимодействие со связанными сущностями (родительская-дочерняя) (добавление, смена родительской сущности), 3) вычисляемые свойства (которые меняются при изменении полей).
Мнение автора: на основании своего опыта я выступаю скорее за анемичную модель: когда сущность в основном контейнер для данных, почти не содержащий логику, и наборе команд/сервисов для взаимодействия с ними (и именно на команды ложиться ответственность за сохранение консистентности агрегатов).
Для меня вполне допустим следующий вариант: в доменной логике мы не создаем и не редактируем сущности напрямую, а делаем это через ISetter компонент. В контракт конкретного ISetter мы закладываем способы создания и изменения сущности. В таком случае у нас есть компонент, который указывает на контракт и допустимые способы взаимодействия с конкретной сущностью.
Пример поведения, располагаемого в ISetter: 1) типизированные билдеры под конкретные сценарии использования (инварианты), 2) взаимодействие со связанными сущностями (родительская-дочерняя) (добавление, смена родительской сущности), 3) вычисляемые свойства (которые меняются при изменении полей).