Предметно-ориентированное проектирование.

Справляйтесь со сложностью в самом сердце ПО, явно моделируя бизнес-домен и удерживая эту модель — и код, который её выражает, — в тесном согласии с языком людей, понимающих домен.

По мере роста системы бизнес-правила склонны рассеиваться по контроллерам, сервисам и запросам к базе данных. Код отдаляется от того, как бизнес на самом деле говорит о своей работе, поэтому каждый разговор нуждается в переводе, а каждое изменение рискует нарушить правило, о котором никто не помнил.

Проектирование, центрированное на данных, усугубляет это: модели становятся анемичными мешками геттеров и сеттеров, инварианты не живут нигде конкретно, и система медленно превращается в "большой ком грязи", к которому осмеливаются прикасаться лишь немногие.

Предметно-ориентированное проектирование атакует проблему на двух уровнях.

Стратегическое проектирование делит большой домен на ограниченные контексты — явные границы, внутри которых модель и её язык согласованы, — и отображает связи между ними. Каждый контекст волен моделировать одно и то же понятие по-разному там, где бизнес действительно видит его по-разному.

Тактическое проектирование строит богатую модель внутри контекста из небольшого набора строительных блоков и настаивает на едином языке: одни и те же термины появляются в разговорах, в модели и в коде.

Тактические строительные блоки:

• Сущности — объекты, определяемые идентичностью, которая сохраняется во времени (Customer, Order).
• Объекты-значения — неизменяемые объекты, определяемые своими атрибутами (Money, Address).
• Агрегаты — кластеры сущностей и объектов-значений с единственным корнем агрегата, который охраняет инварианты кластера и является единственной точкой входа для изменений.
• Репозитории — коллекциеподобные интерфейсы, загружающие и сохраняющие целые агрегаты, скрывая детали хранения.
• Доменные сервисы — операции без состояния, которые естественно не принадлежат одной сущности.
• Доменные события — записи о чём-то значимом, что произошло в домене.

Стратегические блоки — ограниченный контекст и карта контекстов — организуют эти модели по командам и подсистемам.

• Применяйте его, когда основная сложность в бизнес-правилах, а не в технологии — логистика, финансы, страхование, планирование.
• Применяйте его, когда нескольким командам нужно прийти к согласию об общем, развивающемся понимании домена.
• Избегайте его для простых CRUD-приложений или приложений ввода данных, где накладные расходы на моделирование дают мало.

1. Беседуйте с экспертами предметной области и выделяйте единый язык; записывайте термины и их значения.
2. Определите ядро домена — часть, дающую конкурентное преимущество, — и сосредоточьте усилия моделирования там.
3. Разделите домен на ограниченные контексты и нарисуйте карту контекстов с их взаимосвязями.
4. Внутри контекста моделируйте агрегаты так, чтобы каждый обеспечивал свои инварианты в одной транзакции.
5. Загружайте и сохраняйте агрегаты через репозитории; публикуйте доменные события о том, что важно другим контекстам.
6. Постоянно совершенствуйте — модель никогда не «готова», она развивается по мере углубления понимания.