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