Комментарии 36
Макс, мне кажется, что такое описание ubiquitous language может сбить с толку.
Единый язык создается не для проекта, а для контекста. И в каждом контексте слово «заказ» будет обозначать что-то свое.
Если брать пример из активити диаграммы, там может быть пяток контекстов (магазин, разные менеджеры). При этом везде будет заказ, но со своими атрибутами, со своим бизнес-процессом. И уход от единой универсальной модели Заказа и есть избежание антипаттерна GodObject.
У Эванса в книге язык создавался для проекта. Правда, там язык появлялся сразу, а концепция контекстов - довольно далеко. Но, я с ним согласен, потому что есть тезис: все члены проекта общаются на одном едином языке, это важно. Если проект включает несколько контекстов - значит язык их должен как-то включать все вместе. И если речь везде идет о Заказе покупателя - то там один Заказ. А если у нас есть Заказ покупателя в интернет-магазин и Заказ на доставку в транспортную компанию, то слово Заказ становится запрещенным, надо пояснять. Причина, почему язык один в том, что люди с громадным трудом переключаются между языками в ходе одной коммуникации. Путаница будет, не будут выдерживать. А то, что в разных контекстах для заказа покупателя могут быть важны важны разные атрибуты - понятно.
Я так и не понял — что такое модель, и чем она отличается от требований...
Требования - описание системы как черного ящика, без описания конструкции. Модель - описание устройства системы, ее работы.
"Если для идентификации и аутентификации пользователя выбрано решение "пара логин/пароль", система должна предоставлять пользователю возможность восстановления забытого пароля" -- это описание системы как черного ящика, или устройства системы? Или её работы? Это требование или модель? Или это производное требование, появляющееся в результате выбора конструкции?
"В таблице со списком сделок должна быть возможность изменения ширины столбцов. Система должна автоматически сохранять установленную ширину столбцов и восстанавливать её для всех столбцов при последующем открытии таблицы сделок" -- это требования или модель? Они описывают систему как черный ящик, или описывают устройстово системы? Если это требования, то можно ли без них обойтись и заменить их моделью? Что это за модель? Если описание устройства системы даёт преимущества по сравнению с требованиями, то как должно выглядеть это описание применительно к данному случаю?
Оба примера - требования, ни не раскрывают устройство системы. Модель возникает, например, когда описывается способ восстановления пароля. И дальше этот способ можно оценить с точки зрения безопасности: не сможет ли с его помощью злоумышленник получить доступ от имени конкретного пользователя, зная логин, но не зная пароля.
Аналогично про ширину колонок: сохранять настройки можно на локальном рабочем месте, или в настройках, связанных с логином пользователя (могут быть и другие варианты). В первом случае пользователь, войдя с другого компьютера все свои настройки теряет и наоборот, другой пользователь с того же компьютера получает чужие настройки. А во втором - будут сложности если пользователь работает с разных рабочих мест с разным разрешением экрана. В зависимости от того, насколько пользователю важна настройка внешнего вида таблицы сделок для его работы, могут быть разные решения.
Вырезка из учебника по алгебре.
Алгебраической системой <A;WF;WR> называется объект, состоящий из трёх множеств: непустого множества A, множества алгебраических операций WF, определёных на A, и множества отношений WR, определёных на A. Множество A называется носителем алгебраической системы. Если алгебраическая система не содержит операций, она называется моделью, если не содержит отношений, то – алгеброй.
Но в данном случае у нас не алгебра, а разработка софта, и там моделью системы является представление, описывающее конструкцию системы, обычно в каком-то формализме. Например, в виде объектов, их атрибутов и методов. При этом атрибуты можно по смыслу сопоставить с отношениями, а методы - с операциями. Модель в ООП методы включает. Без них получаем только модель данных.
Кажется что тема не раскрыта совсем. Не до конца понятно зачем нужны ограниченные контексты и как общий язык меняется в этих контекстах. Упомянул модель акторов:
Классические объекты с обработкой через вызовы методов плохо отражают такую архитектуру, ик требуются другие методы представления устройства софта, понятные бизнесу.
по этому предложению абсолютно непонятно почему объекты не подходят для использования в системах с очередями. Нужны примеры.
Спасибо, учту на будущее. Потому что когда рассказываешь что-то с чем давно работаешь, не очевидно, что может быть непонятно. Попробую ответить.
Ограниченный контекст возникает из границ проекта. Сейчас прошло время больших монолитных систем, покрывающих какую-то предметной область. Собственно, оно давно прошло, все ERP - из крупных модулей. Но вот представления о том, что модель предметной области надо строить на всю область, с которой имеешь дело - осталось. А в результате ты разрабатываешь систему оптовых продаж, но она интегрируется с системами склада и ведения остатков, а в них работают не только с оптовыми продажами клиентам, но и с отгрузкой в розничные магазины, перевозками между складами и поставками. При этом эти системы в плане модернизации в перспективе может быть замена и этих систем тоже. И в результате аналитики пробовали построить модель оптово-розничной торговли целиком, задача получалась неподъемной. Или аналогично с банком или бухгалтерией - при проектировании главной книги пытались учесть все виды сделок, а их очень много. Выделение ограниченных контекстов позволяет с этим конструктивно работать. В том числе - не тянуть в модели для новых систем понятия, сформированные на основе старых, даже если с ними предусмотрена интеграция.
Почему объекты не подходят для описания работы с очередями? Потому что в них методы выполняются синхронно и результат обработки запроса гарантирован. В классических приложениях многое обеспечивали транзакции - у тебя был или успех, или откат при обработке запроса пользователя. Особая обработка возникала редко. А если у тебя асинхронная обработка на очередях, то там транзакции - в рамках обработки одного сообщения, инстанс может упасть, его работа откатится - а сообщения останутся и будут обработаны. И это - не внутреннее дело разработчика, многое из этого имеет бизнес-последствия, как минимум - вываливается на службу поддержки и это надо обсуждать со стейкхолдерами на понятном им языке. Модель акторов это позволяет. А классическая объектная модель перестает соответствовать реализации на сервисах, на ней эти ситуации обсуждать нельзя.
Но про модель акторов я в статье подробно не писал, это есть в докладе. на который ссылка. Возможно, в будущем напишу отдельную статью.
«Таким образом, получалось две модели: модель предметной области, обычно в виде бизнес-процессов, с которой работал бизнес-аналитик»
Модель предметной области всегда была прежде всего онтологической моделью, сначала — ER-диаграммой (смотри методологию IDEF1FX 70-х годов и моду на ERWin в 90-х), потом — UML Class (см RUP и OOA).
Модель предметной области обычно фиксирует общее устройство реальности в отрасли (статическая модель отношений явлений и бизнес-объектов), а не в конкретной компании — в этом её сила для повторного использования (см Analysis Patterns Фаулера) и в этом же её слабость (см неуспех той же книжки).
Модель процессов обычно описывает устройство процессов в конкретной компании, а не в отрасли, т.к. считается, что они сильно изменчивы от компании к компании, хотя и есть инициативы типы APQC Reference Model, но они видимо известны только бизнес-архитекторам (https://www.apqc.org/resource-library/resource-listing/apqc-process-classification-framework-pcf-cross-industry-excel-10)
Мне как инженеру и разработчику БД было нормальное рисовать концептуальные модели предметки как онтологии, но заказчикам их пользу приходилось объяснять с большим трудом.
Когда в роли бизнес-аналитиков стали выступать вчерашние лингвисты и экономисты, им конечно было проще описывать модель процессов, а не домена.
Ну и, что самое важно, заказчикам процессные модели были понятнее, чем онтологические и формально правильные.
И в целом побеждали и победили смешанные неформальные модели деятельности с объектами swimlane flowchart, откуда вылез и закрепился успех BPMN (а теперь глядишь и Event Storming).
Да, именно так: заказчикам процессные модели понятнее, чем онтологические, поэтому вместо онтологических моделей начали писать просто словарь понятий предметной области, и рисовать только процессы. А объекты появлялись уже только при проектировании приложения, в виде ER-схемы БД. Хотя был шаблон Business Object от Фаулера, который как раз говорил про использование модели предметной области как основе для проектирования объектов, что предполагало, что модель объектов мы все-таки создаем.
BPMN предполагает указание объектов и Archimate - тоже. Но без подробной проработки их структуры и атрибутов. А этого недостаточно.
«DDD предложил так же, через объекты, описывать предметную область, а затем прозрачно отражать объекты предметной области в код.»
Описывать предметную область через объекты предложил не DDD, а ещё OOA — Object-Oriented Analysis (and Design) Гради Буча и компании: https://www.wikiwand.com/en/Object-oriented_analysis_and_design
Насколько я понимаю, прозрачно отражать объекты предметной области в код предложил не DDD, а сами создатели объектно-ориентированных языков типа SmallTalk и те же соавторы OOAD в форме UML и RUP.
Это уже потом пришли ремесленники и нагородили паттернов типа инъекций, фасада, фабрики и т.д., за которыми стало не видно ключевых объектов приложения, моделирующих реальность.
Ну, да. Шаблон Business Objects был еще у Фаулера, и OOAD тоже в эту сторону работал. А параллельно развивались шаблоны, ориентированные чисто на структурирование кода - инъекции, фасады, фабрики. Проблема в том, что без них ты от Business Objects получал антипаттерн BigObject - потому что бизнес-объекты реально многообразны. А DDD предложил принцип: объекты предметной области должны прозрачно и единообразно отражаться в код. Не обязательно 1:1, это лишь самый простой способ. Можно для каждого делать DTO, контроллер, фабрику - но это должно быть единообразно. И наследование тоже можно реализовывать по-разному, но тоже единообразно.
«Это был следующий шаг по отношению к рекомендованному на этапе анализа составлению словаря предметной области: мы говорим, что у нас теперь будет не просто словарь понятий, а набор объектов со своими атрибутами и методами.»
И опять-таки всё это было и мы практиковали в середине 2000-х благодаря UML, RUP и Iconix.
Мы делали объектную модель анализа.
«Таким образом, DDD сместил фокус от описания системы как черного ящика к описанию внутреннего устройства, или системы прозрачного ящика.»
От многих аналитиков-проектировщиков и раньше и сейчас требуют, чтобы они описывали структуру системы и её частей, ранее через UML-диаграммы Крухтеновского 4+1 и подсистемы-модули по ГОСТ + алгоритмы обработки данных и даже сигнатуры вызовов и DDL-скрипты и диаграммы классов Boundary-Control-Entity, а сейчас — через C4-модель.
В общем сейчас ты похож на фанатиков-агилистов, которые утверждают, что до agile в софтверной индустрии была голь перекатная и один waterfall :)
я напомню, что в RUP были 3 сквозных процесса-дисциплины на эту тему:
Business Modeling
Requirements
Analysis and Design
не сводилось всё к требованиям и чёрному ящику
Вот смотри: сначала делаем бизнес-модель, потом из нее - требования (черный ящик), потом на их основе - дизайн. При этом требования - граница между работой бизнес-аналитика и системного аналитика, именно они сшивают модели. И именно поэтому к ним внимание, чтобы обеспечить посыл: "система, удовлетворяющая требованиям будет решать бизнес-задачу". А так - не работает. И сила DDD в том, что он три разных процесса объединил в работу с одной моделью. Напрямую прослеживая на основе модели, как такой софт будет поддерживать бизнес-процессы на требуемом уровне.
«Они заменили две модели, предметной области и системы, на единую модель, описанную на едином языке проекта.»
Какая модель имеется в виду? Модель чего, системы?
«На рисунке мы видим описание бизнес-процессов в виде activity diagram, диаграмму классов для документов и диаграмму состояний документов, которые и реализуют бизнес-процесс. Но при этом все три модели — на едином языке и с прозрачной связью между ними. И принципы DDD говорят, что в коде информационной системы должны присутствовать те же самые объекты, а не какая-то другая реализация.»
Если ты тут показываешь модель системы, то я её тут не вижу, есть модель автоматизируемой деятельности и её правил.
«Этим DDD в значительной мере обесценил требования как таковые и внимание к ним.»
Опять-таки, ещё раньше требования были сначала обесценены use case'ами, а после — user stories.
При этом проблема формулирования качественных ограничений, в том числе показателей качества, остаётся и DDD вроде никак её не решает.
«Ведь если заказчик и пользователи понимают модель системы, то они сами могут оценить, подойдет она для их целей или нет. »
А почему это не сработало с макетами интерфейсов? Вроде макеты интерфейсов — это тоже модель системы. Вот тебе вход, вот выход. Чего не хватило? Диаграммы алгоритмов? Ок, вот макет интерфейса + диаграмма алгоритма. Зачем DDD?
Потому что макеты интерфейсов не раскрывают структуру системы. Ты добавил на заказ в интерфейсах магазина поле "комментарий для курьера как проехать" или даже возможность подгрузить туда рисунок - а этого мало, еще надо протянуть через интеграцию через все системы до мобильного рабочего места курьера и там показать. Или сделал признак на заказе "отгружать по предоплате" - тоже надо учесть в алгоритмах, чтобы если предоплаты нет - склад не начинал собирать заказ и, главное, не отгрузил его. Куча прецедентов, когда про все эти связи забывали, а просто дорисовывали интерфейс.
«Еще одно важное изменение, которое принес DDD, — признание, что единую непротиворечивую модель предметной области построить невозможно, а значит и не стоит браться за эту задачу.»
Насколько помню, те же самые идеологи и методисты ErWin говорили, что для построения модели надо выбирать точку зрения и большую модель бить на части.
смотри:
« Для более удобной работы с большими моделями в ERwin предусмотрены подмножества модели (Subject Area), в которые можно включить тематически общие сущности.»
https://studfile.net/preview/5828092/page:16/
1999-й год, даже не 21-й век!
что говорит именно DDD, и что я понял не сразу — что он предлагает один и тот же объект реального мира моделировать по-разному, а не просто разбивать на контексты. в этом есть большой смысл, которого не было ранее
ERwin да, предлагал. Но это - уже проектирование БД, этап дизайна, а не бизнес-модели. А вот что модель предметной области должна быть целостной и непротиворечивой - учебники писали.
вот у меня другое понимание, что ER-модели прежде всего моделируют мир в автоматизируемой части.
да, с целью последующего создания хранилища этой модели, но моделируют они мир, а не хранилище как таковое, по крайней мере, на концептуальном уровне модели:
Nevertheless, the central goal of IDEF1 and LDDT was the same: to produce a database-neutral model of the persistent information needed by an enterprise by modeling the real-world entities involved.
conceptual model aims to express the meaning of terms and concepts used by domain experts to discuss the problem, and to find the correct relationships between different concepts.
https://en.wikipedia.org/wiki/Conceptual_model_(computer_science)
«Вместо этого предложено предметную область делить на ограниченные контексты, в рамках каждого из которых строить свою модель, сопрягая их теми же способами, которыми в объектном подходе сопрягаются разные системы или фрагменты системы: через выделение общего ядра с наследованием, создание специальных прослоек-переводчиков или иным образом.»
А что, бизнес-заказчики хорошо понимают, что такое «общее ядро с наследованием» и тем более «прослойки-переводчики»? Как я писал выше про онтологическое моделирование, в моём опыте это не так.
Если бизнес-заказчикам объяснять, что "вот эти объекты у нас будут во всех системах одинаковы" или "мы не будем поддерживать структуру объектов старой legacy-системы, у нас будет другая структура, и мы будем делать преобразования при интеграции" - понимают. Но да, важны объяснения в понятных им терминах. Это проблема, такая же как с диаграммами классов - она очень богатая, чтобы бизнес-заказчики ее понимали - надо использовать разумное подмножество, ограничивать себя. Иначе ты что-то нарисовал, и думаешь что объяснил важное, а они думают "ну, здесь какие-то непонятные значки, наверное техническое и неважное".
Большое спасибо за такие развернутые комментарии! Когда из этого буду делать доклады или другие материалы - обязательно учту наше обсуждение!
Domain Driven Design: модели вместо требований