# БИБЛИОТЕКА Курсы Системная инженерия Теория ограничений Управление Linux Сознание, интеллект Политэкономия Сумма технологии Экстраполяция в будущее АНАЛИТИКА Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Микросервисы ESB Solution Design DDD РАЗРАБОТКА Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Continuous Integration git Frontend HTTP/REST Apache Регулярка JS Perl ТЕСТИРОВАНИЕ Ресурсы QA и QC Цикл тестирования 1 Тест-анализ 2 Тест план 3 Тест-дизайн и покрытие Уровни тестирования Виды тестирования Баг-репорт Шаблоны XPATH Безопасность Нагрузочное Android Автоматизация Selenium Генератор ИНН ДАННЫЕ Об информации SQL MongoDB
Эта страница:
Черпнуть мудрости Суть Использовать со стилями и шаблонами DDD + Hexagonal... heretic
Ещё в этом разделе:
АРХИТЕКТУРА Solution Design Document DDD
Другие разделы:
# АНАЛИТИКА АРХИТЕКТУРА ДАННЫЕ РАЗРАБОТКА БИБЛИОТЕКА ТЕСТИРОВАНИЕ
Domain Driven Design
Черпнуть мудрости
  • PDF Вон Вернон. Предметно-ориентированное проектирование. Самое основное. (2017)
  • Как сварить кашу из микросервисов. Автор критикует подход сервис-сущность, предлагает подход сервис-бизнес-процесс вкупе с CQRS.

Архитектура ПО

Суть

Domain Driven Design (объяснение от А. Левенчука) это когда Разработчик сначала слушает не мутные требования Клиента, но те слова, которые он употребляет. Тем самым определяя онтологию (предметную область) того что хочет Клиент. И её начинает реализовывать на самом нижнем уровне, добавляя в объектную модель те сущности, названия которых употреблял Клиент. А затем, уже когда Клиент более-менее сам начинает понимать что он хочет - просто перекомпоновывает и дорабатывает.

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

The premise of domain-driven design is the following:

  • placing the project's primary focus on the core domain and domain logic;
  • basing complex designs on a model of the domain;
  • initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.

Контекст (Context) = семантическая граница, набор, появляющиеся в котором слова или утверждения определяют его значение.

Домен (предметная область, domain) = сфера знаний, влияния или деятельности. The subject area to which the user applies a program is the domain of the software;

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

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

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

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

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

Добавить связь с OODA?

Добавить связь с бизнес-слоем?

ИТ-архитектура

Два функциональных ядра Архитектуры (cores)

  • Аналитическое ядро (analytics core), читает/анализирует:
    • Карточки Клиентов
    • очки скоринга Клиентов (scoring)
    • поведение Клиента
      (что-то подобное реализовано в Яндекс.Деньги - выявление отклонений в действиях Клиента на основе статистики)
    • workflow Бизнес-процессов (на основе статистики прохождения шагов, сравнения постан дч)
    • нагрузку шин ПО адаптерам И потокам данных
    • (?)риски (risks)
  • Синтезирующее ядро (synthesis core), создаёт/изменяет:
    • правила скоринга Клиентов (scoring rules)
    • workflow Бизнес-процессов
      (требует настраиваемого workflow - Camunda?)
    • Продукты (Products)
    • Сервисы (Services)
    • Маркетинговых Кампаний (marketing)
    • правила работы Шины (bus rules)

Максимально автоматизированы.

Мантия Архитектуры (mantle)

Мантия 1 (mantle 1)
  • т.н. demilitarized zone (DMZ)
    • авторизация (authentication, authorization)
    • маршрутизация (routing)
    • балансировщик нагрузки (load balancer)
    • служба логирования (logging service)
    • репликация данных сессии (session replication)
    • т.н. автоматический "размыкатель" (circuit breaker)
    • служба аудита (audit service)
Мантия 2 (mantle 2)
  • шина для командных запросов (command queries bus)
  • шина для событийных запросов (event bus). RabbitMQ?
    • (event dispatcher)
    • (event handlers)
    • хранилище событий (event store)
    • (replay events)
    • ...

Возможные каналы доставки/взаимодействия (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.