Суть
Domain Driven Design (Проектирование на основе предметной области) = подход, предложенный Эриком Эвансом для эффективного проектирования и реализации приложений в сложных предметных областях. Основой его является создание модели будущей системы на едином языке (ubiquitous launguage), разрабатываемом для проекта и обеспечивающим надёжные коммуникации между всеми его участниками.
Модель, описанная на этом языке, согласуется с бизнес-заказчиком и верифицируется им, а затем отражается в реализацию системы с использованием типовых шаблонов, так что элементы и конструкции модели могут быть прослежены в коде. Таким образом обеспечивается соответствие поведения готовой системы потребностям заказчика, без чего сложные IT-проекты едва ли могут стать успешными.
Простым языком: DDD это когда Разработчик сначала внимательно слушает не мутные требования Клиента (бизнес-заказчика), а те слова, которые он употребляет, тем самым определяя предметную область интересов Клиента. Это дело уже можно с яростным энтузиазмом упорядочивать в модель. И уже эту модель можно начинать реализовывать на самом нижнем уровне, добавляя в объектную модель те сущности, названия которых употреблял Клиент.
А затем, уже когда Клиент более-менее сам начинает понимать что он хочет — разработчик перекомпоновывает и дорабатывает тот набросок.
Ограниченный контекст (bounded context) = семантическая граница, окружающая модель предметной области, содержащиеся в ней слова и утверждения, области проблем и области решений. Именно в рамках ограниченного контекста компоненты ПО делают определённые вещи, соответствующие контексту.
Модель предметной области = система абстракций, которая описывает аспекты сферы знаний, влияния или деятельности. Она может быть использована для решения проблем/задач, связанных с этой сферой. Модель предметной области это представление значимых концепций реального мира, относящихся к материальным аспектам, которые необходимо моделировать в ИС. Понятия включают данные, используемые в бизнесе, и правила, которые Предприятие применяет в отношении этих компонентов.
Иными словами, модель предметной области = сущности + бизнес-логика + события предметной области.
Сущности = словарь предметной области, что делает доступным представление для не-технических стейкхолдеров и для тех, кто является новичком в предметной области.
Модель предметной области должна быть свободна от конкретных технологий.
Карта доменов / Карта контекстов (Context map) = графический инструмент, который позволяет описать связи между отдельными доменами.
Домен (предметная область, domain) = сфера знаний, влияния или деятельности. Домен ПО = предметная область, в которой пользователь использует ПО.
Смысловое ядро (core domain) = самый главный домен, наиболее ёмко характеризующий Бизнес. Смысловым ядром называется ограниченный контекст, который разрабатывается как ключевая стратегическая инициатива организации.
Примеры доменов:
Домен |
Контекст |
Поддомены |
работа с Клиентами |
b2c / b2b, всё, что относится к работе с Клиентами |
|
заказы |
|
|
биллинг (система расчётов) |
Содержит в себе все финансовые операции. Обеспечивает взаимодействие с процессинговым центром. |
|
доставка |
b2e, всё, что относится к работе с курьерами |
- принятие заказа
- исполнение заказа
- отслеживание статуса заказа
|
система статистики |
Сбор и обработка (не выдача) аналитической информации. |
|
система менеджмента |
Выдача аналитической информации. Инструментарий управленческих решений. |
|
Использовать со стилями и шаблонами
Как базовую архитектуру для DDD можно использовать:
-
Ports and adapters architecture (Hexagonal architecture). Ports & Adapters Architecture
-
EDA, event-driven architecture. Событийно-ориентированная архитектура. Event-driven architecture.
- CQRS, command-query responsibility segregation. CQRS.
- SOA, Service-oriented architecture. Сервис-ориентированная архитектура (SOA)
- Microservices
Черновик некоторой ереси
Добавить связь с OODA?. Что такое OODA
Добавить связь с бизнес-слоем?
Два функциональных ядра Архитектуры (cores)
-
Аналитическое ядро (analysis core), читает/анализирует:
- Карточки Клиентов
- очки скоринга Клиентов (scoring)
-
поведение Клиента
(что-то подобное реализовано в Яндекс.Деньги — выявление отклонений в действиях Клиента на основе статистики)
- workflow Бизнес-процессов (на основе статистики "прохождения" блоков бизнес-шагов отработки блоков бизнес-функций)
- нагрузку шин ПО адаптерам И потокам данных
- риски (risks) — обозначает
-
Синтезирующее ядро (synthesis core), создаёт/изменяет:
- Карточки Клиентов
- правила скоринга Клиентов (scoring rules)
-
workflow Бизнес-процессов
(требует настраиваемого workflow — Camunda?)
- Продукты (Products)
- Сервисы (Services)
- Маркетинговые кампании (marketing)
- правила работы Шины (bus rules)
Максимально автоматизированы.
Мантия Архитектуры (mantle)
Мантия 1 (
mantle 1), внутренняя
- шина для командных запросов (command queries bus)
-
шина для событийных запросов (event bus). RabbitMQ?
- (event dispatcher)
- (event handlers)
- хранилище событий (event store)
- (replay events)
- ...
Мантия 2 (
mantle 2), внешняя
-
т.н. demilitarized zone (DMZ)
- авторизация (authentication, authorization)
- маршрутизация (routing)
- балансировщик нагрузки (load balancer)
- служба логирования (logging service)
- репликация данных сессии (session replication)
- т.н. автоматический "размыкатель" (circuit breaker)
- служба аудита (audit service)
Возможные каналы доставки/взаимодействия (delivery channels)
- Лицом к лицу — курьер (Face2Face.Courier). исх
- Лицом к лицу — отделения Банка (Face2Face.Branches). вх/исх
- Мобильные — Приложение — Андроид (Mobile.App.Android). вх/исх
- Мобильные — Приложение — iOS (Mobile.App.iOS). вх/исх
- Мобильные — SMS (Mobile.SMS). вх/исх
- Интернет — Сайт — десктопная версия (Web.Desktop). вх
- Интернет — Сайт — мобильная версия (Web.Mobile). вх
- Интернет — Сайт — GUI-доступ для Администраторов (Web.AdminGUI). вх.
- Интернет — Консольный доступ для Администраторов по SSH. (Web.CLI). вх.
- Банкоматы (ATM). вх
- Платёжные терминалы (POS / ATM.mini). вх
- Телефонные звонки — Колл-центр (Phone.CallCenter). вх/исх
- Телефонные звонки — Озвучивание заранее записанных сообщений Клиенту (Phone.IVR). исх
- Email. вх/исх
- Партнёры (Partners). вх/исх
- Государство — законодательное API (Partners.Government.Legislative)
-
Государство — различные сервисы Единого Окна (Partners.Government.SingleWindowService)
Например, Госуслуги
- Общественное питание (Partners.FoodService, Partners.Catering)
- Здравоохранение (Partners.Healthcare)
- Образование (Partners.Education)
- Страхование (Partners.Insurance)
- Розничная торговля (Partners.Retail)
- Телекоммуникации (Partners.Telecom)
- др. Банки (Partners.Banking)
- агенты недвижимости (Partners.Estate)
- киоски/стенды (Kiosk). вх/исх
- социальные сети (SocialNetworks) вх/исх
- ТВ (TV). исх. возможно, стоит отнести как подраздел к Партнёры
- гейминг (Gaming). вх/исх . возможно, стоит отнести как подраздел к Партнёры
- имплантируемые микрочипы (MicrochipImplant). вх/исх
вх/исх — относительно организации
Безопасность каналов (security)
- шифрование протоколов передачи данных (encryption)
-
физическая невидимость для посторонних передаваемых физических предметов, шевеления губ при переговорах (visibility).
На физическом уровне, например, это перегородки.
-
физическая неслышимость для посторонних переговоров Клиента с Организацией (audibility).
На физическом уровне. например, это перегородки.
Чем выше безопасность для Канала Доставки — тем более широкий спектр Сервисов/Продуктов он может "поддерживать".
Что должны поддерживать каналы
- многоязычность (Multi-Language)
- многовалютность (Multi-Currency)
- ...
Методы аутентификации (authentification)
? По степени возрастания надёжности:
-
пароль (password)
- многоразовый пароль
- одноразовый пароль
-
биометрия (biometric)
- радужная оболочка глаза
- отпечатки пальцев
-
мультифакторная аутентификация (multi-factor authentication)
Например, пароль + SMS ИЛИ пароль + биометрия..
Верификация методом электронной цифровой подписи (digital signature).
Чем надёжнее метод аутентификации при использовании Канала Доставки — тем более широкий спектр Сервисов/Продуктов он может "поддерживать", тем меньше физических контактов необходимо между представителями Организации и Клиентом.
Также, например, передача копий документов, заверенных ЭЦП (электронной цифровой подписью) ликвидирует необходимость в физическом контакте с Клиентом.
Инфраструктура (infrastructure)
Обязательные функциональные модули/подсистемы:
-
Библиотека/репозиторий Правил Регуляторов (regulators rules)
-
Интернациональные правила (international)
- законы (legis, laws)
- институциональные/предметная_область (institutional, domain). Например, SWIFT.
- Национальные правила (national)
- Местные/локальные правила — регион страны, населённый пункт (local)
- Библиотека/репозиторий Продуктов
- Библиотека/репозиторий Сервисов
- Библиотека/репозиторий шаблонов Документов
- Библиотека/репозиторий Карточек Клиентов
- Cимулятор ЖЦ Продукта/Сервиса (simulation)
- ...
Должны иметь доступный в интрасети API.