От монолитных моделей предметной области – к модульным

Максим ЦепковАрхитектор и бизнес-аналитик CUSTIS

Санкт-Петербург, 18 февраля 2017 World Information Architecture Day

Приложения давно модульные, а модель предметной области часто хотят построить на общей непротиворечивой системе понятий

Шина

Поставки Каталог товаров Продажи

Склад Финансы

2/21

Бизнес-слой

Слой приложений Модульный

IT-ландшафт

Единая модель

Это основано на убеждении, что существует непротиворечивая и целостная картина мира, которую мы можем не знать, но выясняем

?

3/21

Может быть, в мире идеальных объектов Платона и Декарта так и есть, но на практике целостная картина оказывается слишком жесткой

4/21

Купля-продажа

Разрабатывая Domain Driven Design, Эрик Эванс осознал эту проблему и предложил решение*

О нем я расскажу

* Эрик Эванс. DDD. Часть IV «Стратегическое проектирование»

5/21

Решение – ограниченный контекст

6/21

Предметную область следует разделить на ограниченные контексты (bounded context)

Целостность удерживается за счет карты этих контекстов (context map)

Имена (понятия) включаются в единый язык Для изоляции контекстов применяем те же подходы

ООП, что и для разработки софта Для работы с похожими контекстами тоже применяем

подходы ООП

Как работать с контекстами?

7/21

Шаблоны работы с контекстами

Карта контекстов Context map

Единый язык Ubiquitous language

Заказчик и поставщикCustomer-Supplier teams

КонформистConformist

Служба с открытым протоколом

Open host service

Общедоступный язык Published language

Отдельное существование Separate ways

Предохранительный уровень

Anticorruption layer8/21

Общее ядро Shared kernelОграниченный

контекст Bounded context

Кейс 1. Товарные документы в торговле

Я не буду пересказывать книгу. Я расскажу кейсы из своего опыта

9/21

Счет-фактура

Накладная

Счет

Заказ

Документы в оптовых продажах

Намерения о сделке согласуем с покупателем

В случае продажи по предоплате

По факту отгрузки

Для учета НДС (наполнение – как в накладной)

Основной документ – накладная, она фиксирует факт сделки и сумму за отгрузку

10/21

Компания Покупатель

Документы в закупках

Основным документом стал Invoice: мы его оплачиваем и ожидаем товар, принимая на него заказы

11/21

Счет-фактура

Приходная накладная

Invoice

Заказ

КомпанияПоставщик

В закупках – похоже, но есть нюансы

Что принял наш склад

Для учета НДС (приходит с товаром)

Что мы хотели купить

Что поставщик обещал прислать

Сделка одинакова: купля-продажа Но компания занимает разные позиции в сделке Восприятие всегда зависит от позиции

Почему так по-разному?

И не стоит объединять поставки и продажи в один контекст на основе типа сделки

12/21

Контексты товарных документов

ПродажиПоставки

Бухгалтерия

Склад

Язык торговых сделок

Бухгалтерия интерпретирует

сделки по-своему

Поставки и продажи почти независимы

Склад сам фиксирует ответственность за товар

Общий язык, он объединяет все контексты

13/21

Опирайтесь на структуру деятельности компании, делите ее на связанные области

Согласуйте понятийные интерфейсы для коммуникации на границах областей

Используйте язык сделок из общей и отраслевой культуры

Учитывайте позицию компании в сделке Соотносите внутренний язык компании

с языком, принятым в культуре

Выводы: как разделить контексты операционных документов?

14/21

В понятийном аппарате всегда отпечатаны текущие информационные системы

Нормированные области и системы диктуют взаимодействие другим – шаблон конформист

Если предполагается замена системы, то изменится и язык, подготовьтесь к этому: Используйте язык из культуры отрасли, а не старые шаблоны

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

Зависимость контекстов не должна мешать независимому развитию областей бизнеса

Выводы: как определить взаимодействие контекстов?

15/21

Кейс 2.Каталог товаров в торговле

Казалось бы, очевидно: товары с атрибутами, поделенные на группы иерархическим классификатором

16/21

Одна классификация – удобно, но чью точку зрения брать за основу? Закупающих товар (разделение по группам производства)? Менеджеров по оптовым продажам (разделение по группам клиентов)? Тех, кто размещает товар в магазине (разделение по тематике

размещения)? Продавцов (разделение по комплементарным товарам)? Покупателей интернет-магазина (разделение по рекламному

представлению)?

На 80–90% группы совпадают, но не на 100% Лыжные перчатки – с перчатками или горными лыжами? Мелочь, которая продается у касс, – где она в каталоге? А услуги и промо-комплекты – где они в каталоге? Еще не купленные товары поставщиков в каталоге есть?

Как классифицировать товары?

17/21

Таможенные декларации

Контексты каталога

Классификация и атрибуты

для закупающих

Классификация и атрибуты

для размещения в магазинеАтрибуты

для логистов

Классификация и атрибуты

для интернет-магазина

Описания для сервисного

центра

Общее ядро каталога товаров

18/21

Разные взгляды на справочники реализуются через атрибуты, например: Договорились, что товарная группа – для каталога

продаж, а категория товара – для закупающих Группе клиента соответствует подразделение, ведущее

продажи, а категории клиента – правило оплат

Но часто этого не хватает, и тогда люди ведут собственные Excel с классификацией

Есть ли контексты у справочников в системах вендоров?

И теперь вы будете понимать, почему это происходит

19/21

Области ограниченных контекстов совпадают – они объединяют людей

Как правило, в каждой области – свои документы, есть интерфейсы передачи

Справочники – общие, но у каждого свой взгляд на их наполнение

Поэтому применяются разные шаблоны для взаимодействия контекстов

Контексты справочников и документов: сходства и различия

20/21

Множество контекстов – фича, а не баг Единая целостная модель –

непрактичный миф прошлого Модель мира зависит от позиции,

контексты – адресные

Работаем с контекстами на практике Предметную область делим на ограниченные контексты

(bounded context) Целостность держит карта контекстов (context map)

и единый язык (ubiquitous language)

Подводя итоги

Есть вопросы? Обращайтесь!Максим Цепков mtsepkov.org

21/21

Это не очевидно, особенно из опыта небольших проектов