По пунктам: 1. Существует бекенд, в котором сервисы Calculator и PartnerService зависят друг от друга неявным образом через сервис ContractService. То есть в изображенной структуре все зависят ото всех и изменения в любом из компонентов прямо или косвенно оказывает влияение на все 5 компонентов. 2. Посредством моделирования (этот процесс за скобками, можно использовать классический DDD, можно Event Storming, можно Domain Storytelling, да даже исходя из Business Capabilities) были определены границы и эти границы наложены на существующее решение. Мы видим на изображении, что Contract, Partner и ContractService по текущей внутренней реализации одновременно востребован и в контексте Sales и в контексте Risk Assessment. 3. Здесь изображеная целевая картинка, как может выглядеть декомпозиция. В Sales остается ContractService, в Risk Assessment остается PartnerService. Но остается вопрос: «а что делать с общей сущностью?». И ответ далеко не очевиден, потому что если посмотреть только на данные, то вроде как они нужны и там и там. Проблема в том, что зачастую в самих данных, в самих атрибутах нет метаданных об использовании этих атрибутов в тех или иных бизнес-операциях, контекстах, бизнес-процессах. Эту информацию приходится воссоздавать, чтобы определить какие данные в каком контексте какой смысл несут. Это важнейший аспект и как раз его нарушение ведет к появлению тех самых распределенных монолитов.
Как с этим быть? 4. В рамках моделирования и определения Ubiquitous Language (по сути языка, в котором каждый термин имеет однозначеное значение в заданной границе) мы выясняем, что в контексте Risk Assessment нет понятия signContract(), соответственно в этом контексте нет и термина для атрибута signatureDate. При этом исследуя Sales мы видим, что в этом контексте, контексте Продаж, нет понятия voteContract и в нем не определены термины ceditRating и votingResult. То есть здесь явным образом в одном сервисе и в одной сущности смешаны понятия из двух разных моделей. Негативное следствие этого – увеличение общей сложности, зависимости, размытие ответственности, ну и как следствие – подобная реализация сдерживает развитие каждой модели в отдельности. Что с этим делать?
Есть два варианта, безопасный именее безопасный.
Безопасный показан на изображении: 5. Мы явно в рамках существующего сервиса делаем дубликат сущности Contract и сервиса ContractService и проводим рефакторинг внутри существующего сервиса. Например, это могут быть разные пакеты со своими интерфейсами. 6. В каждом из пакетов мы вычищаем то, что не относится к конкретному контексту, то есть проводим рефакторинг. Рефакторинг это ровно потому, что поведение не меняется, меняется только структура. 7. Получаем в рамках все того же монолита два пакетета, в рамках каждого из которых только сущности и методы, имеющие смысл в рамках определенного контекста.
Теперь о неточностях в изображении. Возможно автор поторопился и есть нюанс, который вызывает вопросы, а именно, то, что на изображении (3) отсутствует сервис ContractService, хотя на последущих слайдах он указывает, что такой сервис существует. Это нисколько не меняет сути описанного подхода. Можно мысленно представить, что на изображении (3) есть еще один сервис ContractService, смысл не меняется совершенно, так как смысл ровно в том, каким образом разорвать зависимость.
Менее безопасный вариант: Мы сразу выносим физически сервис ContractService в отдельный контекст, теперь у нас по инстансу ContractService в Sales и Risk Assessment, и проводим рефакторинг двух сервисов параллельно.
По пунктам: 1. Существует бекенд, в котором сервисы Calculator и PartnerService зависят друг от друга неявным образом через сервис ContractService. То есть в изображенной структуре все зависят ото всех и изменения в любом из компонентов прямо или косвенно оказывает влияение на все 5 компонентов. 2. Посредством моделирования (этот процесс за скобками, можно использовать классический DDD, можно Event Storming, можно Domain Storytelling, да даже исходя из Business Capabilities) были определены границы и эти границы наложены на существующее решение. Мы видим на изображении, что Contract, Partner и ContractService по текущей внутренней реализации одновременно востребован и в контексте Sales и в контексте Risk Assessment. 3. Здесь изображеная целевая картинка, как может выглядеть декомпозиция. В Sales остается ContractService, в Risk Assessment остается PartnerService. Но остается вопрос: «а что делать с общей сущностью?». И ответ далеко не очевиден, потому что если посмотреть только на данные, то вроде как они нужны и там и там. Проблема в том, что зачастую в самих данных, в самих атрибутах нет метаданных об использовании этих атрибутов в тех или иных бизнес-операциях, контекстах, бизнес-процессах. Эту информацию приходится воссоздавать, чтобы определить какие данные в каком контексте какой смысл несут. Это важнейший аспект и как раз его нарушение ведет к появлению тех самых распределенных монолитов.
Как с этим быть? 4. В рамках моделирования и определения Ubiquitous Language (по сути языка, в котором каждый термин имеет однозначеное значение в заданной границе) мы выясняем, что в контексте Risk Assessment нет понятия signContract(), соответственно в этом контексте нет и термина для атрибута signatureDate. При этом исследуя Sales мы видим, что в этом контексте, контексте Продаж, нет понятия voteContract и в нем не определены термины ceditRating и votingResult. То есть здесь явным образом в одном сервисе и в одной сущности смешаны понятия из двух разных моделей. Негативное следствие этого – увеличение общей сложности, зависимости, размытие ответственности, ну и как следствие – подобная реализация сдерживает развитие каждой модели в отдельности. Что с этим делать?
Есть два варианта, безопасный именее безопасный.
Безопасный показан на изображении: 5. Мы явно в рамках существующего сервиса делаем дубликат сущности Contract и сервиса ContractService и проводим рефакторинг внутри существующего сервиса. Например, это могут быть разные пакеты со своими интерфейсами. 6. В каждом из пакетов мы вычищаем то, что не относится к конкретному контексту, то есть проводим рефакторинг. Рефакторинг это ровно потому, что поведение не меняется, меняется только структура. 7. Получаем в рамках все того же монолита два пакетета, в рамках каждого из которых только сущности и методы, имеющие смысл в рамках определенного контекста.
Теперь о неточностях в изображении. Возможно автор поторопился и есть нюанс, который вызывает вопросы, а именно, то, что на изображении (3) отсутствует сервис ContractService, хотя на последущих слайдах он указывает, что такой сервис существует. Это нисколько не меняет сути описанного подхода. Можно мысленно представить, что на изображении (3) есть еще один сервис ContractService, смысл не меняется совершенно, так как смысл ровно в том, каким образом разорвать зависимость.
Менее безопасный вариант: Мы сразу выносим физически сервис ContractService в отдельный контекст, теперь у нас по инстансу ContractService в Sales и Risk Assessment, и проводим рефакторинг двух сервисов параллельно.
5Telegram Channel avatar size/dimensions Healing through screaming therapy Co-founder of NFT renting protocol Rentable World emiliano.eth shared the group Tuesday morning on Twitter, calling out the "degenerate" community, or crypto obsessives that engage in high-risk trading. How to create a business channel on Telegram? (Tutorial) How to Create a Private or Public Channel on Telegram?
from us
