Domain Driven Design (Предметно ориентированный проектирование) - это один из подходов проектирования программных продуктов нацеленный в первую очередь на решение проблем бизнеса. Основная задача - изучение предметной области предприятия с целью получения решения в терминах и задачах бизнеса. Программисты при таком подходе должны говорить с бизнесом на одном языке - языке предметной области.

Литература

Реализация методов предметно-ориентированного проектирования

Предметно-ориентированное проектирование. Структуризация сложных программных систем

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

Единый язык (Ubiquitous Language) - выверенный набор непротиворечивых терминов из бизнес области. Очень часто на практике - это аббревиатуры.

Ограниченный Контекст (Bounded Context) - явно ограниченная область, в рамках которой существует модель предметной области. Контекст служит для разделение системы на части (модули, компоненты)

Контекст может быть не один, но в каждом контексте есть только один единый язык.

Предметная область (Domain) - это бизнес задачи и их окружение. Состоит из:

• Смысловое ядро (Core domain)
• предметные подобласти (Subdomains)
• служебные подобласти (supporting subdomain)

Пространство задач - набор задач для формирования смыслового ядра

Пространство решений - один или несколько ограниченных контекстов, набор конкретных моделей.

Карта контекстов - пространство решений в разрезе контекстов.

Модель предметной области (Domain Model) - один из самых популярных реализаций предметной области в рамках контекста

Шаблоны, концепцции и понятия - разработка в стиле DDD не обязывает использовать какие-то конкретные шаблоны, но в книге Эванса перечисляются следующие шаблоны:

• Value object - объект, который имеет смысл как комбинация его аттрибутов
• Entity - самостоятельная сущность, основная строительная единица
  • Хранилища (Repositories)
  • Агрегаты (Aggreates)
  • Фабрики (Factories)
• Service - сервисная операция, которая имеет смысл в рамках всего контекста

Прямое следование советам из книги

Идея представления проекта через призму DDD не может быть полно описана одной книгой. Более того в книге рассматриваются конкретные примеры, которые не могут быть воспроизведены один в один.

В реальной жизни вопросы и ответы предметной области будут иными.

Ограничение только предметной областью задачи

Бизнес-логика приложения не является единственной проблемой, которую должен учитывать архитектор. Более того, в самой книге рассмотрена слоистая архитектура, подразумевающие дополнительные задачи, не касающиеся бизнеса.

Попытки использовать только предложенные структурные элементы

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

Попытки свести DDD к водопадным методикам проектирования

Описание DDD подразумевает, что есть этап формулирования и осмысления, есть этап реализации. Из-за чего складывается ощущение, что это "водопадная методика", но эволюционные методы и гибкая разработка тоже работают, просто не надо определять все сразу и идеально.

Слоистая архитектура

В книге Эванса приведен пример слоистой архитектуры, в итоге попытки использовать ее и только ее оказываются провальными. Можно и нужно совмещать идеи DDD с разными архитектурными стилями и шаблонами.

MVC не может быть DDD

Часто популярные шаблоны считают не совместимыми, хотя, например, MVC является полностью совместимой с DDD.

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

Состоит из нескольких шагов

• определить события
• определить команды
• определить действующих лиц
• определить представления
• определить агрегаты

• Общая архитектура
• Event Storming
• Концептуальная модель
• Архитектура обмена данными
• Структура модуля
• Тесты
  • Юнит
  • Интеграционный

Общая архитектура

Event Storming

Концептуальная модель

Архитектура обмена данными

Структура модуля

Тесты