От монолитных моделей предметной области - к модульным. http://mtsepkov.org/OOP4Ontology - страница доклада на WIAD-2017 в Петербурге

1. От монолитных моделей
предметной области –
к модульным
Максим Цепков
Архитектор и бизнес-аналитик CUSTIS
Санкт-Петербург, 18 февраля 2017
World Information Architecture Day

2. Приложения давно модульные,
а модель предметной области
часто хотят построить на общей
непротиворечивой системе понятий
Шина
Поставки
Каталог
товаров Продажи
Склад Финансы
2/21
Бизнес-слой
Слой
приложений Модульный
IT-ландшафт
Единая модель

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

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

5. Разрабатывая Domain Driven Design,
Эрик Эванс осознал эту проблему
и предложил решение*
О нем я расскажу
* Эрик Эванс. DDD. Часть IV «Стратегическое проектирование»
5/21

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

7.  Предметную область следует разделить
на ограниченные контексты (bounded context)
 Целостность удерживается за счет карты этих
контекстов (context map)
 Имена (понятия) включаются в единый язык
 Для изоляции контекстов применяем те же подходы
ООП, что и для разработки софта
 Для работы с похожими контекстами тоже применяем
подходы ООП
Как работать с контекстами?
7/21

8. Шаблоны работы с контекстами
Карта контекстов
Context map
Единый язык
Ubiquitous
language
Заказчик и поставщик
Customer-Supplier teams
Конформист
Conformist
Служба с открытым
протоколом
Open host service
Общедоступный язык
Published language
Отдельное
существование
Separate ways
Предохранительный уровень
Anticorruption layer
8/21
Общее ядро
Shared kernel
Ограниченный
контекст
Bounded context

9. Кейс 1.
Товарные документы в торговле
Я не буду пересказывать книгу.
Я расскажу кейсы из своего опыта
9/21

10. Счет-фактура
Накладная
Счет
Заказ
Документы в оптовых продажах
Намерения о сделке
согласуем с покупателем
В случае продажи
по предоплате
По факту отгрузки
Для учета НДС
(наполнение – как в накладной)
Основной документ – накладная,
она фиксирует факт сделки и сумму за отгрузку
10/21
Компания Покупатель

11. Документы в закупках
Основным документом стал Invoice: мы его оплачиваем
и ожидаем товар, принимая на него заказы 11/21
Счет-фактура
Приходная
накладная
Invoice
Заказ
КомпанияПоставщик
В закупках – похоже, но есть нюансы
Что принял
наш склад
Для учета НДС
(приходит с товаром)
Что мы
хотели купить
Что поставщик
обещал прислать

12.  Сделка одинакова: купля-продажа
 Но компания занимает разные позиции в сделке
 Восприятие всегда зависит от позиции
Почему так по-разному?
И не стоит объединять поставки и продажи
в один контекст на основе типа сделки
12/21

13. Контексты товарных документов
Продажи
Поставки
Бухгалтерия
Склад
Язык торговых сделок
Бухгалтерия
интерпретирует
сделки по-своему
Поставки и продажи
почти независимы
Склад сам фиксирует
ответственность за товар
Общий язык,
он объединяет все контексты
13/21

14.  Опирайтесь на структуру деятельности компании,
делите ее на связанные области
 Согласуйте понятийные интерфейсы
для коммуникации на границах областей
 Используйте язык сделок из общей и отраслевой
культуры
 Учитывайте позицию компании в сделке
 Соотносите внутренний язык компании
с языком, принятым в культуре
Выводы: как разделить контексты
операционных документов?
14/21

15.  В понятийном аппарате всегда отпечатаны
текущие информационные системы
 Нормированные области и системы диктуют
взаимодействие другим – шаблон конформист
 Если предполагается замена системы, то изменится
и язык, подготовьтесь к этому:
 Используйте язык из культуры отрасли, а не старые шаблоны
компании
 При необходимости сделайте предохранительный уровень
 Зависимость контекстов не должна мешать
независимому развитию областей бизнеса
Выводы: как определить
взаимодействие контекстов?
15/21

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

17.  Одна классификация – удобно, но чью точку зрения
брать за основу?
 Закупающих товар (разделение по группам производства)?
 Менеджеров по оптовым продажам (разделение по группам клиентов)?
 Тех, кто размещает товар в магазине (разделение по тематике
размещения)?
 Продавцов (разделение по комплементарным товарам)?
 Покупателей интернет-магазина (разделение по рекламному
представлению)?
 На 80–90% группы совпадают, но не на 100%
 Лыжные перчатки – с перчатками или горными лыжами?
 Мелочь, которая продается у касс, – где она в каталоге?
 А услуги и промо-комплекты – где они в каталоге?
 Еще не купленные товары поставщиков в каталоге есть?
Как классифицировать товары?
17/21

18. Таможенные
декларации
Контексты каталога
Классификация
и атрибуты
для закупающих
Классификация
и атрибуты
для размещения
в магазинеАтрибуты
для логистов
Классификация
и атрибуты
для интернет-
магазина
Описания
для сервисного
центра
Общее ядро
каталога товаров
18/21

19.  Разные взгляды на справочники
реализуются через атрибуты, например:
 Договорились, что товарная группа – для каталога
продаж, а категория товара – для закупающих
 Группе клиента соответствует подразделение, ведущее
продажи, а категории клиента – правило оплат
 Но часто этого не хватает, и тогда люди
ведут собственные Excel с классификацией
Есть ли контексты у справочников
в системах вендоров?
И теперь вы будете понимать, почему это происходит
19/21

20.  Области ограниченных контекстов совпадают –
они объединяют людей
 Как правило, в каждой области – свои документы,
есть интерфейсы передачи
 Справочники – общие, но у каждого свой взгляд
на их наполнение
 Поэтому применяются разные шаблоны
для взаимодействия контекстов
Контексты справочников
и документов: сходства и различия
20/21

21.  Множество контекстов – фича, а не баг
 Единая целостная модель –
непрактичный миф прошлого
 Модель мира зависит от позиции,
контексты – адресные
 Работаем с контекстами на практике
 Предметную область делим на ограниченные контексты
(bounded context)
 Целостность держит карта контекстов (context map)
и единый язык (ubiquitous language)
Подводя итоги
Есть вопросы? Обращайтесь!
Максим Цепков mtsepkov.org
21/21
Это не очевидно,
особенно из опыта
небольших проектов