Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, perekrestov, Вы писали:

P>>А это не приводит к анемичной модели со всеми вытикающими последствиями?
S>Озвучите последствия — озвучу как мы с ними боремся (или не боремся)


Ну, о приимуществах/недостатках повторяться не хочется. Тут

Автор: GlebZ
Дата: 27.05.09

все хорошо обсудили

Могу, конечно, скопипастить с wiki

Logic cannot be implemented in a truly object-oriented way unless wrappers are used, which hide the anemic data structure.

Violation of the encapsulation and information hiding principles.

Necessitates a separate business layer to contain the logic otherwise located in a domain model. It also means that domain model's objects cannot guarantee their correctness at any moment, because

their validation and mutation logic is placed somewhere outside (most likely in multiple places).

Necessitates a global access to internals of shared business entities increasing coupling and fragility.

Facilitates code duplication among transactional scripts and similar use cases, reduces code reuse.

Necessitates a service layer when sharing domain logic across differing consumers of an object model.

Makes a model less expressive and harder to understand.

Но, меня не сильно интересует вопрос Anemic vs Rich domain model.

Меня интересует реализация. Как реализовать/спроектировать упомянутую мною проблему следуя DDD.

S>У нас модель данных отвечает за структуру и инварианты предметной области (разумеется речь не о всей модели, а об её представлении для конкретного клиента), контроллеры — за поведение приложения в соответствии с БЛ заказчика. Каждая часть решает свою задачу, смешивать их не хотим.