• PDF Вон Вернон. Предметно-ориентированное проектирование. Самое основное. (2017)
• Как DDD помог нам построить новые ревизии в пиццериях. О тактических паттернах DDD в разработке: агрегатах, командах, доменных эвентах, прикладной службе и интеграции ограниченных контекстов (2020)
• Ценности DDD (2020)
• Что и как спросить у бизнеса, чтобы проработать ИТ-решение (2020). О DDD с 21-й минуты, буквально несколько минут.

Об архитектуре приложения

• DDD, Hexagonal, Onion, Clean, CQRS, ... How I put it all together (2017)
  DDD, Hexagonal, Onion, Clean, CQRS... как я собрал всё это вместе (Перевод, 2018)
• More than concentric layers (2018)
  Больше, чем концентрические слои (Перевод, 2018)
• Reflecting architecture and domain in code (2019)
• Documenting Software Architecture (2019): UML, 4+1 Architectural view model, Architecture Decision Records, The C4 Model, Dependency diagrams, Application Map.

Построение микросервисной архитектуры

• Как сварить кашу из микросервисов (2019). Автор критикует подход сервис-сущность, предлагает подход сервис-бизнес-процесс вкупе с CQRS.
• Использование микросервисов с шаблонами DDD и CQRS для решения сложных бизнес-задач
• Use domain analysis to model microservices
• Use tactical DDD to design microservices
• Identify microservice boundaries

Локальные ресурсы

• Что такое бизнес-процесс
• Что такое архитектурные слои
• Кратко о мастер-данных и Master Data Management

Domain Driven Design (Проектирование на основе предметной области) = подход к проектированию и реализации приложений в сложных предметных областях, основа подхода в создании модели будущей системы на базе т.н. Единого Языка (ubiquitous launguage) = терминов предметной области.
Модель, описанная на этом языке, согласуется с бизнес-заказчиком и верифицируется им, а затем отражается в реализацию системы с использованием типовых шаблонов, так что элементы и конструкции модели могут быть прослежены в коде. Таким образом обеспечивается смысловая связь между потребностями заказчика и структурой и поведением IT-системы, без чего сложные IT-проекты едва ли могут стать успешными.

DDD и ООП прекрасно сочетаются.

Проще говоря: DDD это когда аналитик сначала внимательно слушает не мутные требования Клиента (бизнес-заказчика), а те слова, которые он употребляет, тем самым определяя предметную область интересов Клиента. Ключевые термины можно с яростным энтузиазмом упорядочивать в модель IT-системы, они же будут встречаться в бизнес-процессах. Примеры таких терминов предметной области: накладная, клиент, платёж.
Эту модель можно решительно реализовывать на самом нижнем уровне — в виде объектной модели, в которую добавляются те сущности, названия которых являются ключевыми в процессах Клиента.
А затем, уже когда Клиент более-менее сам начинает понимать что он хочет — ИТ-специалисты перекомпоновывают и дорабатывают набросок.

Бизнес действует в некоторой сфере знаний / влияния / деятельности.
В этой сфере есть Домены (domain — предметная область) a.k.a. Ограниченные контексты (bounded context) = смысловые границы, группирующие содержащиеся в ней слова и утверждения, области проблем и области решений. Именно в рамках ограниченного контекста компоненты ПО делают определённые вещи, соответствующие контексту.

Смысловое ядро, основной домен (core domain) = самый главный домен, наиболее ёмко характеризующий Бизнес. Смысловым ядром называется ограниченный контекст, который разрабатывается как ключевая стратегическая инициатива организации.

Совокупность доменов / контекстов, представленная в графическом виде, являет собой Карту контекстов (Context map) = графический инструмент, который позволяет описать связи между отдельными доменами.
Например:

Модель предметной области = сущности + бизнес-логика + события предметной области.
Словарь предметной области = перечень сущностей IT-системы, что делает доступным представление для не-технических стейкхолдеров и для тех, кто является новичком в предметной области.

• модель надо строить практически сразу, уже при неполной информации, это нормально;
• модель следует достраивать и перестраивать по поступлению новой / уточняющей информации;
  Это позволяет контролировать достоверность модели — сохранять минимальным потенциальный разрыв между моделью и реальным миром;
• модели должны быть модульны, а не монолитны (привет ООП!);
• всегда контролируйте удобство модели для восприятия её всеми участниками проекта, в том числе для потенциально новых участников;
• Модель предметной области должна быть свободна от указания конкретных технологий реализации;
• текстовые описания, дополняющие модель, это нормально.

Примеры доменов:

Домен	Контекст	Поддомены
работа с Клиентами	b2c / b2b, всё, что относится к работе с Клиентами
заказы
биллинг (система расчётов)	Содержит в себе все финансовые операции. Обеспечивает взаимодействие с процессинговым центром.
доставка	b2e, всё, что относится к работе с курьерами	принятие заказа исполнение заказа отслеживание статуса заказа
система статистики	Сбор и обработка (не выдача) аналитической информации.
система менеджмента	Выдача аналитической информации. Инструментарий управленческих решений.

Как базовую архитектуру для DDD можно использовать:

1. Ports and adapters architecture (Hexagonal architecture). Ports & Adapters Architecture
2. EDA, event-driven architecture. Событийно-ориентированная архитектура. Event-driven architecture.
3. CQRS, command-query responsibility segregation. CQRS.
4. SOA, Service-oriented architecture. Сервис-ориентированная архитектура (SOA)
5. 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)

? По степени возрастания надёжности:

1. пароль (password)
   • многоразовый пароль
   • одноразовый пароль
2. биометрия (biometric)
   • радужная оболочка глаза
   • отпечатки пальцев
3. мультифакторная аутентификация (multi-factor authentication)
   Например, пароль + SMS ИЛИ пароль + биометрия..

Верификация методом электронной цифровой подписи (digital signature).

Чем надёжнее метод аутентификации при использовании Канала Доставки — тем более широкий спектр Сервисов/Продуктов он может "поддерживать", тем меньше физических контактов необходимо между представителями Организации и Клиентом.
Также, например, передача копий документов, заверенных ЭЦП (электронной цифровой подписью) ликвидирует необходимость в физическом контакте с Клиентом.

Инфраструктура (infrastructure)

Обязательные функциональные модули/подсистемы:

• Библиотека/репозиторий Правил Регуляторов (regulators rules)
  • Интернациональные правила (international)
    • законы (legis, laws)
    • институциональные/предметная_область (institutional, domain). Например, SWIFT.
  • Национальные правила (national)
  • Местные/локальные правила — регион страны, населённый пункт (local)
• Библиотека/репозиторий Продуктов
• Библиотека/репозиторий Сервисов
• Библиотека/репозиторий шаблонов Документов
• Библиотека/репозиторий Карточек Клиентов
• Cимулятор ЖЦ Продукта/Сервиса (simulation)
• ...

Должны иметь доступный в интрасети API.