# Процессы Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Архитектура Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Vision (Концепция) Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD Анализ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Сервисы DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux Тестирование Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Тестирование требований Тест-анализ и тест дизайн Интеграционное, API, E2E Тест план Метрики качества Автотесты Selenium XPATH Нагрузочное Данные Ресурсы MDM Big data Об информации SQL intro MongoDB intro Библиотека Системная инженерия Станислав Лем Экстраполяция в будущее Политэкономия Сознание, интеллект

/ АНАЛИЗ АРХИТЕКТУРА: + АРХИТЕКТУРА + Vision + Solution Design + ESB + Микросервисы и service mesh + HTTP/REST + RPC - DDD | Черпнуть мудрости | Суть | Использовать со стилями и шаблонами | Черновик некоторой ереси ДАННЫЕ DevOps Gaming Библиотека ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Domain Driven Design
latest update of the page: 27-01-2024, 09:53 UTC
Черпнуть мудрости

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

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

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

Суть

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

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

Ограниченный контекст (bounded context) = семантическая граница, окружающая модель предметной области, содержащиеся в ней слова и утверждения, области проблем и области решений. Именно в рамках ограниченного контекста компоненты ПО делают определённые вещи, соответствующие контексту.

Модель предметной области = система абстракций, которая описывает аспекты сферы знаний, влияния или деятельности. Она может быть использована для решения проблем/задач, связанных с этой сферой. Модель предметной области это представление значимых концепций реального мира, относящихся к материальным аспектам, которые необходимо моделировать в ИС. Понятия включают данные, используемые в бизнесе, и правила, которые Предприятие применяет в отношении этих компонентов.
Иными словами, модель предметной области = сущности + бизнес-логика + события предметной области.
Сущности = словарь предметной области, что делает доступным представление для не-технических стейкхолдеров и для тех, кто является новичком в предметной области.
Модель предметной области должна быть свободна от конкретных технологий.

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

Домен (предметная область, domain) = сфера знаний, влияния или деятельности. Домен ПО = предметная область, в которой пользователь использует ПО.

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

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

Домен Контекст Поддомены
работа с Клиентами 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.