Для себя хочу иметь заметку про DDD в которой кратко будет все что нужно занать про DDD. "кратко" - это, скорее всего, не возможно в формате заметки или даже целой статьи... Но почему бы и не попробовать.
Domain-Driven Design: Everything You Always Wanted to Know About it, But Were Afraid to Ask
Domain-driven design: рецепт для прагматика
DDD: Strategic Design: Core, Supporting, and Generic Subdomains
Как приручить DDD. Часть 1. Стратегическая
Как приручить DDD. Часть 2. Практическая
Что такое DDD ?
Много разных определений на все вкусы:
Domain-Driven Design - это борьба со сложностью бизнес-процессов и их автоматизации и реализации в коде
Domain-Driven Design - это единый язык между экспертами и программистами
Domain-Driven Design - это набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит бизнес-логика, устанавливающая связь между реальными условиями области применения продукта и кодом.
Domain-Driven Design - is a major software design approach, focusing on modeling software to match a domain according to input from that domain's experts.
Domain-Driven Design - is an approach to software design that glues the system’s implementation to a constantly evolving model, leaving aside irrelevant details like programming languages, infrastructure technologies, etc…
Как это работает?
Из определений становится немного понятней, что DDD - это некий подход к проектированию приложений который основа на том что мы в первую очередь выражаем в коде сущности из предметной области. И надеимся что очередной рефакторинг или новый состав команды не убьет нашу идею. "описываем сущности из предметной области" - в идеале значит что эксперт смотрящий в наш код должен видеть в нем сушности из своего мира.
Мы на верном пути к DDD если в обсуждениях фич, бизнес-логики люди используют термины которые и для разработчиков и для экспертов имеют одинаковое значение.
Немного деталей как устроено DDD
-
Domain / Домен - глобальная предметная область
-
Subdomain / Поддомен - бизнес задача, обладают высокой связностью
-
Core - конкурентное преимущество компании
-
Supporting - не является уникальных знанием компании но без этого все еще нельзя существовать
-
Generic - типовые задачи которые могут быть делегированы третьим лицам, компании
-
Bounded context / Границ поддомена - это ограниченная часть системы, в которой мы реализуем нашу бизнес-логику
-
-
Entity / Сушность - объект у которого есть уникальный идентификатор. Например: покупатель, заказ.
-
Value Object / Объект-значение - объект который описывает характеристики. это атрибуты и они могут быть частью нескольких Entity. Например: адрес.
-
Aggregates / Агрегаты - это кластер сущностей и объектов-значений, объединённых общими инвариантами. Любое взаимодействие с агрегатом осу ществляется через одну и только одну из его сущностей, называемую корнем агрегата.
DDD и микросервисы 
Паттерны
PDF, PATTERNS, PRINCIPLES, AND PRACTICES OF DOMAIN-DRIVEN DESIGN
Особенности и проблемы DDD
-
Хорошо подходит для редкоменяющихся, налаженных бизнес-процессов
-
Много доменных моделей лучше чем одна елинственна на все приложение. Меньше боли при изменениях. Внутри компании могут быть разные понимания одних терминов, процессов.
-
Плохо масштабируется
Книги
Вон Вернон: Реализация методов предметно-ориентированного проектирования PDF, Implementing Domain-Driven Design
Эрик Эванс: Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем PDF, Domain -Driven Design TACKLING COMPLEXITY IN ТНЕ HEART OFSOFTWARE