Прощу прощения за долгую задержку, на работе аврал :(
Тогда у меня вопрос что вы называете анемичной моделью, потому что в текущем контексте я ей зову просто структуру кладущуюся в базу в виде полей+геттеров+сеттеров
Анемичная модель предметной области — это классы-модели без поведения и классы-сервисы без состояния. Если сильно огрублять, то в богатой модели каждой бизнес-сущности соответствует один класс, а в анемичной — два, модель и сервис.
Так ведь в том и дело что контроллировать состояние приходится клиентскому коду,
Состояние контролируют сервисы, которые являются частью модели предметной области и, соответственно, не являются клиентским кодом.
Почему не контролирует? То, что поведение и состояние хранятся в разных классах, не означает, что поведение не может контролировать состояние.
Клиентский код вообще не должен заниматься такими вещами, как консистентность бизнес-данных, вся работа с предметной областью собрана в одном месте и доступна наружу через контракты/API. А как уж она там внутри устроена — богатая модель или анемичная — это вопрос другой, как я уже говорил выше — ортогональный «размазанности» или «скучкованности».
Повторюсь ещё раз — в моём текущем проекте используется анемичная модель предметной области (такая архитектура от предков досталась), но при этом вся бизнес-логика собрана в одном месте, а не размазана по всей системе.
Да я вообще не об этом. Я о том, что анемичная модель, это обязательно «размазано по всему приложению» — это неправда. Можно размазать и анемичную модель, и богатую; и ту, и другую можно собрать в одном месте. Так что включать данное утверждение в определение анемичной модели не стоит.
И это никак не зависит от того, что понимается под моделью предметной области — только данные, только поведение или их совокупность.
“Архитектура с анемичной моделью” не что иное как процедурный подход к созданию архитектуры приложений в котором модель предметной области размазана по всему приложению
В моём текущем проекте используется анемичная модель предметной области, но при этом вся бизнес-логика собрана в одном слое. Так что «модель предметной области размазана по всему приложению» — это не про анемичную модель, вещи ортогональные.
И во фразе Фаулера, которую Вы как бы перевели, об этом ни слова.
Меня раз и навсегда отучили не блокировать компьютер, когда я, вернувшись на рабочее место, обнаружил фото болгарского блондина-пед… ста на весь рабочий стол. До сих пор как вспомню, так вздрогну…
Почему-то Вы сравниваете время жизни версии ОС, коей является Windows XP, и ОС (Linux). Корректнее тогда уж сравнивать Linux со всей линейкой Windows, которой, даже если не считать 3.X и всё, что было до неё, исполнилось уже 21 год, и угасания этой «вспышки» в обозримом будущем не предвидится.
Анемичная модель предметной области — это классы-модели без поведения и классы-сервисы без состояния. Если сильно огрублять, то в богатой модели каждой бизнес-сущности соответствует один класс, а в анемичной — два, модель и сервис.
Состояние контролируют сервисы, которые являются частью модели предметной области и, соответственно, не являются клиентским кодом.
Клиентский код вообще не должен заниматься такими вещами, как консистентность бизнес-данных, вся работа с предметной областью собрана в одном месте и доступна наружу через контракты/API. А как уж она там внутри устроена — богатая модель или анемичная — это вопрос другой, как я уже говорил выше — ортогональный «размазанности» или «скучкованности».
Повторюсь ещё раз — в моём текущем проекте используется анемичная модель предметной области (такая архитектура от предков досталась), но при этом вся бизнес-логика собрана в одном месте, а не размазана по всей системе.
И это никак не зависит от того, что понимается под моделью предметной области — только данные, только поведение или их совокупность.
В моём текущем проекте используется анемичная модель предметной области, но при этом вся бизнес-логика собрана в одном слое. Так что «модель предметной области размазана по всему приложению» — это не про анемичную модель, вещи ортогональные.
И во фразе Фаулера, которую Вы как бы перевели, об этом ни слова.
«Не большой кусок грязи». Чтобы программистам было понятнее: «не (большой кусок грязи (big ball of mud))». :-)