Что-то слишком уж разнятся понимания что же такое Толстая архитектура, а что такое стройная архитектура. Слишком много терминов и разночтений. Попробую пояснить оба этих понятия.
Rich Domain Model, в простонародье, толстая модель, концепция построения логической архитектуры, в которых бизнес-объекты содержат бизнес-логику. Или можно наоборот, бизнес-логика содержит состояние бизнес-объектов.
Anemic Domain Model – почему-то некоторые называют стройной моделью, но особо и не слышал о нормальном(адекватном) русском переводе данного термина. Лично я обычно называю нетолстой моделью. Так понятней. Итак, Anemic Domain Model – концепция построение логической архитектуры, в которой состояние бизнес-объектов разнесено с объектами бизнес-логики обрабатывающих их.
Эти два термина в английском варианте я и буду использовать в дальнейшем, во избежание разночтений.
ФАУЛЕР. Фаулер дал другую терминологию: Transaction Sript и Domain Model. Под Domain Model некоторые понимают Rich Domain Model, что не является правдой, под Transaction Script – Anemic Domain Model. Но если с первым термином не очень логично, второй термин сразу ушел в небытие, и обществом принят не был.
МИФ. Существует миф, что для объектов Rich Domain Model обязательно наличие прозрачных reference между собой. Этот преступный миф не является правдой. Он не имеет отношения ни к Rich, ни к здравому смыслу. А имеет отношение к понятиям statefull, stateless и чисто опциональному lazy load. Единственное отличие, в Anemic – состояние разнесено с методами получения ссылочных объектов. В Rich – это единый объект.
В Anemic:
Employer[] OrganizationService.GetEmployers(Organization org){…}
В Rich:
Employer[] Organization.GetEmployers(){…}
Это немного, однако оно приводит к значительном различии в архитектуре. И та, и другая модель имеет те, или иные достоинства, и недостатки:
Преимущества Anemic:
1. Простота построения. Это большой плюс, ибо главная задача архитектора, реализация функциональности за меньшие деньги. 90 процентов решений, могут быть построены в данной модели и это будет на порядок дешевле.
2. Бизнес-объекты – отчуждаемы. В результате, бизнес-объект может быть спокойно пронесен от DAL, к фасаду и даже далее. Беспрепятсвенно и идентично сериализован/десериализован между физическими слоями. В большинстве, бизнес-объект как бизнес-сущность не меняется при переносе между слоями.
3. Прогнозируемость и управляемость вплоть до DAL. Что под этим понимается. В случае, если вы ворочаете большими объемами данных, в Anemic вам проще управлять запросами к базе данных, чем в Rich. База данных была и остается самой тяжелой частью бизнес приложений. Оптимизация в основном достигается за счет повышения эффективности работы с базой данных(и зачастую не обычным редактирование SQL). В Anemic, вы спокойно можете провести тот, или иной сценарий через соседний сервис, который будет работать именно над этом тяжелым сценарием. В Rich — проблема как с прогнозом результирующего запроса, и с его оптимизацией.
4. Бизнес-объект проще управлять объектами, которые еще не полностью в валидированном состоянии. В Rich – наличие валидаторов обязывает держать валидированное состояние. Что иногда выливается в проблемы(например, когда объект только что создан, не имеет идентификатора, и не имеет тех, или иных ссылок). Во многом, бизнес-объект больше похож на данные, чем на объект в стиле объектного программирования.
Преимущества Rich:
1. Простота использования. Объекты всегда под рукой. Средства обработки объектов, также под рукой. Использовать Rich – значительно проще, особенно когда в проекте новичок.
2. Инкапсуляция. Программисту, использующему данный объект, недоступно его состояние, кроме как определенный интерфейс. Это локализует некоторые изменения в логике. Но тут следует упомянуть, что те изменения, которые касаются состояния, также отслеживаются компиляцией со статической типизацией в Anemic, что покрывает большее количество таких проблем.
3. Меньшее количество мусора. В Anemic приходится отслеживать, чтобы в ворохе сервисов не делали свои велосипеды. В Rich c этим меньше проблем в силу более сильной локализации логики.
Действительность.
Чисто Anemic, а тем более Rich в абсолютно чистом виде не бывает. Бизнес-объект как минимум содержит типизацию, что является частью бизнес-логики, в Rich – по любому приходится делать более высокоуровневые сервисы.
Показания к использованию.
Во многом, IMHO, но…. Если вы ворочаете большими данными, то Anemic по любому. Если ваше приложение простое, то anemic. Если у вас большое количество сущностей, большее чем вы можете запомнить, и это не разбить на модули/компоненты/SOA, в которых будут бегать сотня программистов, то Rich. Но для Rich, нужно сразу запастись инструментальными средствами, типа Hibernate(у которого есть чудный кэш), и средства сериализации/десериализации. Это сгладит недостатки модели.
О себе.
Долгое стародавнее время писал в стиле Rich(вынужден сказать, что не по поводу). Последнее время(а это n лет) пишу только в Anemic.
Теперича можно обсуждать, осуждать, предлагать пойти в лесок с топором погуляти и etc
