🗂 Domain Driven Design: что это такое и зачем оно нужно системному аналитику
Domain-driven design (DDD) — подход проектирования системы и её архитектуры, который берет за основу реальный бизнес и то, как он функционирует.
Для данного подхода справедливо выражение: нет понимания бизнеса — нет системы и её архитектуры. DDD отлично работает для проектов с очень сложными доменным областями и с запутанной бизнес-логикой, которую с наскока не понять.
🎯 Цель DDD — создать общий язык, который будет использоваться всеми участниками проекта: заказчиками, пользователями, разработчиками, тестировщиками и т.д.
Этот язык должен отражать сущности и понятия предметной области, а также их связи и правила. Такой язык называется повсеместным языком (ubiquitous language). Повсеместный язык помогает избежать недопонимания и неоднозначности при общении между участниками проекта.
Простым языком: DDD – когда разработчик сначала внимательно слушает не мутные требования бизнес-заказчика, а те слова, которые он употребляет, тем самым определяя предметную область интересов заказчика.
Это можно упорядочивать в модель. И уже эту модель можно начинать реализовывать на самом нижнем уровне, добавляя в объектную модель те сущности, названия которых употреблял заказчик.
А затем, уже когда заказчик более-менее сам начинает понимать что он хочет — разработчик перекомпоновывает и дорабатывает тот набросок.
Для построения повсеместного языка DDD предлагает разделить предметную область на ограниченные контексты (bounded contexts).
🔲 Ограниченный контекст — это часть предметной области, которая имеет свою собственную модель и свои собственные правила. Внутри одного контекста все сущности и понятия имеют одинаковое значение и интерпретацию. Между разными контекстами под одним и тем же словом могут пониматься разные сущности со своим набором атрибутов и логикой реализации. Например, в контексте продаж клиент — это покупатель товара или услуги, а в контексте поддержки клиент — это получатель помощи или консультации.
Зачем это нужно? Ограниченные контексты помогают изолировать сложность предметной области и упростить моделирование. Каждый контекст можно рассматривать как отдельный микросервис, который реализует свою функциональность и взаимодействует с другими микросервисами.
Роль системного аналитика в DDD
🔹 Общаться с экспертами по предметной области и выяснять их потребности и проблемы.
🔹 Разбивать предметную область на ограниченные контексты и определять границы и связи между ними.
🔹 Строить модель каждого контекста, используя сущности, объекты-значения, агрегаты и корни агрегатов. Эти понятия помогают описать структуру и поведение модели.
🔹 Описывать требования к функциональности, производительности, безопасности и другим аспектам системы в виде пользовательских историй, сценариев, диаграмм и других документов.
🔹 Согласовывать требования с заинтересованными сторонами и обрабатывать запросы на изменение требований.
🔹 Поддерживать актуальность и консистентность модели и требований в течение всего жизненного цикла проекта.
✅ DDD стоит применять, когда
1. вы работаете с микросервисной архитектурой
2. предметная область сложна и динамична
3. есть необходимость в тесном сотрудничестве между разными участниками проекта
❌ DDD не стоит применять, когда
1. предметная область проста и стабильна
2. нет явных экспертов по предметной области
3. система имеет низкую сложность и небольшой объем функциональности
📚 Книги о DDD
1. Вон Вернон. Реализация методов предметно ориентированного проектирования
2. Эрик Эванс. Предметно-ориентированное проектирование (DDD)
📰 Статьи о DDD
1. Domain-driven design: рецепт для прагматика
2. Domain-Driven Design: стратегическое проектирование. Часть 1
3. Domain-Driven Design: тактическое проектирование. Часть 2
#архитектура
➿➿➿➿➿➿➿➿
🧑🎓 Больше статей по этой теме в базе знаний по системному анализу
Domain-driven design (DDD) — подход проектирования системы и её архитектуры, который берет за основу реальный бизнес и то, как он функционирует.
Для данного подхода справедливо выражение: нет понимания бизнеса — нет системы и её архитектуры. DDD отлично работает для проектов с очень сложными доменным областями и с запутанной бизнес-логикой, которую с наскока не понять.
🎯 Цель DDD — создать общий язык, который будет использоваться всеми участниками проекта: заказчиками, пользователями, разработчиками, тестировщиками и т.д.
Этот язык должен отражать сущности и понятия предметной области, а также их связи и правила. Такой язык называется повсеместным языком (ubiquitous language). Повсеместный язык помогает избежать недопонимания и неоднозначности при общении между участниками проекта.
Простым языком: DDD – когда разработчик сначала внимательно слушает не мутные требования бизнес-заказчика, а те слова, которые он употребляет, тем самым определяя предметную область интересов заказчика.
Это можно упорядочивать в модель. И уже эту модель можно начинать реализовывать на самом нижнем уровне, добавляя в объектную модель те сущности, названия которых употреблял заказчик.
А затем, уже когда заказчик более-менее сам начинает понимать что он хочет — разработчик перекомпоновывает и дорабатывает тот набросок.
Для построения повсеместного языка DDD предлагает разделить предметную область на ограниченные контексты (bounded contexts).
🔲 Ограниченный контекст — это часть предметной области, которая имеет свою собственную модель и свои собственные правила. Внутри одного контекста все сущности и понятия имеют одинаковое значение и интерпретацию. Между разными контекстами под одним и тем же словом могут пониматься разные сущности со своим набором атрибутов и логикой реализации. Например, в контексте продаж клиент — это покупатель товара или услуги, а в контексте поддержки клиент — это получатель помощи или консультации.
Зачем это нужно? Ограниченные контексты помогают изолировать сложность предметной области и упростить моделирование. Каждый контекст можно рассматривать как отдельный микросервис, который реализует свою функциональность и взаимодействует с другими микросервисами.
Роль системного аналитика в DDD
🔹 Общаться с экспертами по предметной области и выяснять их потребности и проблемы.
🔹 Разбивать предметную область на ограниченные контексты и определять границы и связи между ними.
🔹 Строить модель каждого контекста, используя сущности, объекты-значения, агрегаты и корни агрегатов. Эти понятия помогают описать структуру и поведение модели.
🔹 Описывать требования к функциональности, производительности, безопасности и другим аспектам системы в виде пользовательских историй, сценариев, диаграмм и других документов.
🔹 Согласовывать требования с заинтересованными сторонами и обрабатывать запросы на изменение требований.
🔹 Поддерживать актуальность и консистентность модели и требований в течение всего жизненного цикла проекта.
✅ DDD стоит применять, когда
1. вы работаете с микросервисной архитектурой
2. предметная область сложна и динамична
3. есть необходимость в тесном сотрудничестве между разными участниками проекта
❌ DDD не стоит применять, когда
1. предметная область проста и стабильна
2. нет явных экспертов по предметной области
3. система имеет низкую сложность и небольшой объем функциональности
📚 Книги о DDD
1. Вон Вернон. Реализация методов предметно ориентированного проектирования
2. Эрик Эванс. Предметно-ориентированное проектирование (DDD)
📰 Статьи о DDD
1. Domain-driven design: рецепт для прагматика
2. Domain-Driven Design: стратегическое проектирование. Часть 1
3. Domain-Driven Design: тактическое проектирование. Часть 2
#архитектура
➿➿➿➿➿➿➿➿
🧑🎓 Больше статей по этой теме в базе знаний по системному анализу