Вот есть действительно сложная система. Сложный домен. Банковский, ритейл, логистика, телеком. Действительно сложные системы состоят из большого количества интегрированных компонентов.
Одни компоненты критичны для бизнеса, другие являются поддерживающими.
Если границы компонентов - технологические, то как вы определите, какие из компонентов являются бизнес-критическими?
Неявным маркером того, что границы технические, является существование компонентных команд. Выглядит это примерно так: у того, кто отвечает за развитие продукта появляется стратегическая инициатива, он садится с кем-нибудь (аналитик/архитектор) и смотрит, в какой десяток-другой систем нужно внести изменения. Немного логики в интеграционной шине, немного логики в одной процедуре в базе, немного логики в другой процедуре в базе, а вот изменение способа коммуникации с клиентом, ага, нужно изменить компонент отправки уведомлений, 4 компонента в CRM….
Остановимся на уведомлениях.
Есть такой закон, 161-П, статья 9.3, банк обязан уведомлять клиента о движении денежных средств. В какой-то момент статья изменилась, теперь банк обязан уведомлять в соответствии с договором… но суть не в этом.
Технологичный, универсальный компонент отправки уведомлений. Если он отправляет 500 различных уведомлений (с днем рождения, с 8 марта, спасибо за покупку) по 5 каналам (смс, пуши, почта, звонок …) и среди этих уведомлений есть одно обязательное, критичное для бизнеса, то компонент автомагически становится бизнес-критическим, хотя бизнес-критичного в нем три копейки. Но вот у него уже совсем иной SLA, статус… ну вы поняли, он стал «золотым» в развитии, тестировании и поддержке.
То же самое происходит, когда вы вносите в интеграционную шину бизнес-логику. Команда шины развивает техническую интеграцию, появление в ней бизнес-логики означает, что теперь есть бизнес-логика, за которую особо никто не отвечает, даже если она бизнес-критичная, но наличие бизнес-критичной логики в паре методов возводит саму шину в сан бизнес-критичных.
Ну и самое интересное. Когда границы компонентов и границы бизнес-возможностей/бизнес-процессов, доменные границы не совпадают мы наблюдаем такую картину:
1. Есть критичный бизнес-компонент
2. Границы десяти компонентов информационной системы проведены не в соответствии с границами предметной области, а технически/технологически/как пришлось
3. От критичного бизнес-компонента (логическая абстракция) в каждом техническом компоненте по 20% логики
4. Все 100% всех пяти компонентов становятся бизнес-критичными
В микросервисах решение этой проблемы лежит буквально в основе самого подхода, но нельзя забывать о том, что унаследованные, монолитные системы ведь тоже живут в этом же домене, в этой же предметной области и они точно так же поддаются проектированию с учетом предметной области.
Основной тезис в том, что даже если вы пошли в модульный монолит (внутренняя модульность), не забывайте о границах самого монолита, в масштабах крупной и сложной системы корректировка этих границ даст больший эффект для всей организации.
Одни компоненты критичны для бизнеса, другие являются поддерживающими.
Если границы компонентов - технологические, то как вы определите, какие из компонентов являются бизнес-критическими?
Неявным маркером того, что границы технические, является существование компонентных команд. Выглядит это примерно так: у того, кто отвечает за развитие продукта появляется стратегическая инициатива, он садится с кем-нибудь (аналитик/архитектор) и смотрит, в какой десяток-другой систем нужно внести изменения. Немного логики в интеграционной шине, немного логики в одной процедуре в базе, немного логики в другой процедуре в базе, а вот изменение способа коммуникации с клиентом, ага, нужно изменить компонент отправки уведомлений, 4 компонента в CRM….
Остановимся на уведомлениях.
Есть такой закон, 161-П, статья 9.3, банк обязан уведомлять клиента о движении денежных средств. В какой-то момент статья изменилась, теперь банк обязан уведомлять в соответствии с договором… но суть не в этом.
Технологичный, универсальный компонент отправки уведомлений. Если он отправляет 500 различных уведомлений (с днем рождения, с 8 марта, спасибо за покупку) по 5 каналам (смс, пуши, почта, звонок …) и среди этих уведомлений есть одно обязательное, критичное для бизнеса, то компонент автомагически становится бизнес-критическим, хотя бизнес-критичного в нем три копейки. Но вот у него уже совсем иной SLA, статус… ну вы поняли, он стал «золотым» в развитии, тестировании и поддержке.
То же самое происходит, когда вы вносите в интеграционную шину бизнес-логику. Команда шины развивает техническую интеграцию, появление в ней бизнес-логики означает, что теперь есть бизнес-логика, за которую особо никто не отвечает, даже если она бизнес-критичная, но наличие бизнес-критичной логики в паре методов возводит саму шину в сан бизнес-критичных.
Ну и самое интересное. Когда границы компонентов и границы бизнес-возможностей/бизнес-процессов, доменные границы не совпадают мы наблюдаем такую картину:
1. Есть критичный бизнес-компонент
2. Границы десяти компонентов информационной системы проведены не в соответствии с границами предметной области, а технически/технологически/как пришлось
3. От критичного бизнес-компонента (логическая абстракция) в каждом техническом компоненте по 20% логики
4. Все 100% всех пяти компонентов становятся бизнес-критичными
В микросервисах решение этой проблемы лежит буквально в основе самого подхода, но нельзя забывать о том, что унаследованные, монолитные системы ведь тоже живут в этом же домене, в этой же предметной области и они точно так же поддаются проектированию с учетом предметной области.
Основной тезис в том, что даже если вы пошли в модульный монолит (внутренняя модульность), не забывайте о границах самого монолита, в масштабах крупной и сложной системы корректировка этих границ даст больший эффект для всей организации.