# БИБЛИОТЕКА Курсы Системная инженерия Стейкхолдеры Теория ограничений Управление Linux Информация Политэкономия Сумма технологии Экстраполяция в будущее АНАЛИТИКА и АРХИТЕКТУРА Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Нотации Архитектура 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
Эта страница:
Черпнуть мудрости Domain Information Model (DIM) Master Data DDD + Hexagonal... heretic
Ещё в этом разделе:
АНАЛИТИКА Нотации Архитектура Solution Design Document DDD
Другие разделы:
# АНАЛИТИКА MONGO DB SQL РАЗРАБОТКА БИБЛИОТЕКА ТЕСТИРОВАНИЕ
Domain Driven Design
Черпнуть мудрости
Domain Information Model (DIM)

Проектирование на основе предметной области (DDD, Domain-driven design) = подход к разработке программного обеспечения для комплексного удовлетворения потребностей, путем сильной связи реализации с основными бизнес-моделями, находящимися в процессе постоянного развития.

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 = The setting in which a word or statement appears that determines its meaning

Domain = A sphere of knowledge (ontology), influence, or activity. The subject area to which the user applies a program is the domain of the software;

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

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

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

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

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

Master Data
Master Data Management (управление основными данными).

Мастер-данные = данные, содержащие ключевую информацию о бизнесе, в том числе о Клиентах, Продуктах, Работниках, о технологиях и материалах. Может иметь набор правил валидации, которым должны удовлетворять данные.

Цель управления основными данными -- удостовериться в

  • отсутствии повторяющихся данных
  • отсутствии неполных данных
  • отсутствии противоречивых данных

Предпосылки к необходимости управления мастер-данными

  1. интеграция различных ИТ-систем
    • одинаковые справочники в разных ИТ-системах;
    • рассинхронизация данных по одним и тем же сущностям в разных ИТ-системах.
  2. Бизнес-процессы, проходящие сквозь несколько ИТ-систем.
  3. потребность в отчётности, использующей данные из разных ИТ-систем.

Чем помогает управление мастер-данными

  1. Облегчает внедрение новых ИТ-систем в инфраструктуру компании
  2. Облегчает интеграцию ИТ-систем
  3. облегчает обработку корпоративных данных
  4. сокращает трудозатраты на актуализацию данных
  5. минимизирует риски, связанные с некорректностью, неактуальностью, несинхронизированностью данных

Что необходимо сделать в рамках Предприятия

  1. Выработка единых правил валидации мастер-данных
  2. Определиться с мастер-системами по мастер-данным
  3. Путём разработки соответствующих регламентов, инструкций, изменений в ПО обеспечить максимальную синхронизацию значений и единоформатность хранения данных в ИТ-системах

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.