Мартин Фаулер считает, что Anemic Domain Model (или бледная доменна модель) это плохо, и антипаттерн, противопоставляя ей Rich Domain Model с интегрированным поведением и бизнес логикой. При этом есть другие мнения, возможно не столь распространенные. Я попробую рассказать об опыте использования Anemic Domain Model при разработке крупного корпоративного приложения. Какие плюсы и минусы мы нашли, и как преодолевали трудности.

1. Anemic Domain Model -
антипаттерн или SOLID ?
Влад Клековкин
главный разработчик
Специализированная Депозитарная Компания Гарант

2. Rich Domain Model
Фаулер рекомендует
Инкапсуляция
Интуитивно понятна
Удобна в использовании
Красивые диаграммы

3. Пример RDM

4. Чего хочет заказчик?
Меняются требования
Иногда законы
Появляются исключения
Специальные пользователи
Особые клиенты

5. Вносим изменения

6. Типичный метод

7. GOD Object рядом

8. Anemic Domain Model
Антипаттерн
Не очевидна в использовании
Нарушение инкапсуляции
Процедурный стиль
Устарело?

9. Пример ADM - Model
public class MyMegaDocument : Document,
IWithStatus, IStartFinishDates,
IPriceSumCount
{
public string Name { get; set; }
public Status Status { get; set; }
public DateTime StartDate { get; set; }
public DateTime FinishDate { get; set;
}
public decimal Price { get; set; }
public decimal Count { get; set; }
public decimal Summ { get; set; }
...
}
interface IWithStatus
{
Status Status { get; set; }
}
interface IStartFinishDates
{
DateTime StartDate { get; set; }
DateTime FinishDate { get; set; }
}
interface IPriceSumCount
{
decimal Price { get; set; }
decimal Count { get; set; }
decimal Summ { get; set; }
}

10. Пример ADM - Logic

11. Пример ADM - Logic

12. Инфраструктура

13. Конфигурируемая логика

14. Eдинственной обязанности
На каждый класс должна быть возложена одна-единственная обязанность.
Открытости/закрытости
Программные сущности должны быть открыты для расширения, но закрыты для изменения.
Подстановки Лисков
Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового
типа, не зная об этом.
Разделения интерфейса
Много специализированных интерфейсов лучше, чем один универсальный.
Инверсии зависимостей
Зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от
модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от
абстракций
Следование SOLID

15. Сравнение

16. Вопросы
Ссылки
http://www.martinfowler.com/bliki/AnemicDomainModel.html
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
https://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/
http://stackoverflow.com/questions/258534/anemic-domain-model-pros-cons
Контакты
kl.vlad@gmail.com
skype: pil00t
Спасибо