О декомпозиции через Ограниченные Контексты Декомпозиция - абсолютно некорректный термин, который тем не менее встречается повсеместно и потому сбивает с толку. И потом очень сложно донести то, что действительно подразумевается под связью между доменом и ограниченным контекстом в DDD. Туда же и декомпозицию монолита на микросервисы (что тоже некорректная формулировка и подход). Давайте разбираться. Традиционная «декомпозиция системы» в инженерном понимании почти всегда подразумевает: 1. есть единая целостная модель системы 2. мы делим ее на части 3. части в совокупности «покрывают» целое (часто еще и без пересечений или с минимальными пересечениями) В таком понимании: - есть единое целое, - есть разбиение этого целого Внезапно, Bounded Context так не работает. И переход от монолита к микросервисам так не работает :) Ограниченные контексты задают семантические срезы (проекции) общей предметной области, внутри которых формируется собственная согласованная модель. То есть мы не делим модель на куски, мы конструируем несколько моделей, которые опираются на: - свой лексикон (Ubiq. Language) - свои инварианты - свой контекст применения То есть Ограниченные Контексты выделяются из предметной области. Самый близкий приземленный пример - это CQRS, где есть модель, в которую данные сохраняются и есть (потенциально несколько) моделей чтения, и это часто не декомпозиция модели записи, а самостоятельные проекции данных. Ровно поэтому для получения независимых сервисов сначала воссоздается предметная область, затем из нее выделяются модели, ограниченные определенным контекстом, и уже они наполняются данными и бизнес-логикой из монолита и, внезапно, какие данные и логика вполне могут начать «дублироваться», какие-то разделяться, какие-то группироваться, потому что наполняют собой разные модели в разных контекстах.