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

Выступление Максима Цепкова, нашего главного архитектора дирекции развития решений, на World Information Architecture Day (18 февраля 2017 года, Санкт-Петербург).

Transcript

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 Это не очевидно, особенно из опыта небольших проектов