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