Как технические границы делают все бизнес-критичным? Ключевой вопрос, которому посвящена эта заметка: «если границы компонентов — технические, как вы определите, какие из них бизнес-критичны?» Представьте универсальный компонент «Сервис уведомлений». Он отправляет 500 различных типов сообщений по разным каналам (sms, push, почта, мессенджер): - С днем рождения - С 8 марта - Спасибо за покупку» - .... Среди этих 500 типов уведомлений есть одно бизнес-критичное: 161-ФЗ, статья 9.4 – «Оператор по переводу денежных средств обязан информировать клиента о совершении каждой операции с использованием электронного средства платежа путем направления клиенту соответствующего уведомления...». Что происходит с компонентом? Он автоматически становится бизнес-критичным. Хотя бизнес-критичного в нем – три копейки. Но теперь у него иной SLA, иной статус. Он стал «золотым» в разработке, тестировании и поддержке. То же самое происходит, когда вы вносите в интеграционную шину бизнес-логику. Команда шины развивает техническую интеграцию, появление в ней бизнес-логики означает, что теперь есть бизнес-логика, за которую особо никто не отвечает, даже если она бизнес-критичная, но наличие бизнес-критичной логики в паре методов возводит саму шину в сан бизнес-критичных. И самое интересное. Когда границы компонентов и границы бизнес-возможностей/бизнес-процессов, доменные границы не совпадают мы наблюдаем такую картину: 1. Есть критичный бизнес-компонент 2. Границы десяти компонентов информационной системы проведены не в соответствии с границами предметной области, а технически/как пришлось 3. От критичного бизнес-компонента в каждом техническом компоненте по 5% логики 4. Все 100% всех десяти компонентов становятся бизнес-критичными В Domain Driven Design решение этой проблемы лежит буквально в основе самого подхода (по сути весь он о том, как проводить границы), но нельзя забывать о том, что унаследованные, монолитные системы ведь тоже живут в этом же домене, в этой же предметной области и они точно так же поддаются проектированию с учетом предметной области. Основной тезис в том, что даже если вы пошли в модульный монолит (внутренняя модульность), не забывайте о границах самого монолита, в масштабах крупной и сложной системы корректировка этих границ даст больший эффект для всей организации. Закончить бы хотелось отсылкой к выступлению Дениса Тимофеева. Денис упоминает «Класс критичности систем». В выступление этот пункт – часть чеклиста при передаче в эксплуатацию и хочется напомнить, что, класс критичности – это то, что распространяется на всю систему, в рамках эксплуатации и если в системе критичного 5%, то все равно, все 100% системы будут критичными, то есть в общем случае вся система унаследует класс критичности самой критичной ее части, даже если это буквально одна функция из тысячи.