Research on Enterprise Business Architecture Design Method Based on Domain-Driven Design
Разбор paper о попытке объединить enterprise architecture и DDD через метамодель из 7 моделей: strategy, organization, process, domain, capability, data и IT service.
Практика чтения для этого источника ещё не опубликована
Ниже доступен готовый редакционный brief из прежнего каталога. Он даёт контекст, но не засчитывается как lab.
Открыть оригиналГотовый редакционный разбор
Он сохранён из прежней версии каталога и расположен после самостоятельной практики, чтобы не подменять чтение оригинала готовым пересказом.
Основа главы
Telegram пост #3075
Краткий обзор paper и разбор идеи объединения enterprise architecture с DDD.
Основа главы
Telegram пост #3075
Краткий обзор paper и разбор идеи объединения enterprise architecture с DDD.
Whitepaper
Research on Enterprise Business Architecture Design Method Based on Domain-Driven Design
Работа Huiwen Deng и Yan Zhao (China Aerospace Academy of Systems Science and Engineering).
Whitepaper
Research on Enterprise Business Architecture Design Method Based on Domain-Driven Design
Работа Huiwen Deng и Yan Zhao (China Aerospace Academy of Systems Science and Engineering).
Paper предлагает метамодель, где enterprise business architecture и DDD работают вместе: стратегия и процессы связываются с доменными границами, данными и IT-сервисами через единый набор моделей.
TL;DR
- Авторы предлагают связать enterprise business architecture и DDD через единую метамодель, чтобы бизнес- и IT-границы описывались согласованно.
- В методе семь моделей: strategy, organization, process, domain, capability, data и IT service.
- Первые три модели в статье даны обзорно, а основной фокус сделан на domain/capability/data/IT service.
- Ключевая идея: доменные объекты и bounded contexts использовать как мост между бизнес-возможностями и логическими границами IT-систем.
Как авторы трактуют бизнес-архитектуру
В основе лежит TOGAF/OMG-подход: business architecture как формальный каркас управления, capability, процессов и данных. В статье этот каркас позиционируется как опора цифровой трансформации и связующий слой между стратегией бизнеса и IT-реализацией.
7 моделей в предложенной метамодели
Strategy model
Стратегические цели, приоритеты и рамки цифровой трансформации.
Organization model
Роли, зоны ответственности и организационная структура.
Process model
Основные бизнес-процессы и их связи.
Domain model
Субдомены, доменные объекты, доменные события и границы контекстов.
Capability model
Базовые capability-компоненты, точки расширения и способ сборки решений.
Data model
Потоки и хранение данных: ETL/ELT, DWH, data lake.
IT service model
State, structure и port как язык описания сервисов и их взаимодействия.
Что подробнее разбирается в статье
Domain model
- Формируются subdomains и bounded contexts как логические границы системы.
- Доменные объекты и события становятся основой для согласования языка бизнеса и IT.
- Именно здесь DDD добавляет детализацию, которой обычно не хватает классическим EA-описаниям.
Capability model
- Определяются базовые capability-компоненты и точки расширения.
- Для каждого capability описываются варианты composable solution design.
- Подход снижает дублирование при сборке новых бизнес-решений.
Data model
- Опора на привычные подходы ETL/ELT и связку DWH + data lake.
- Фокус на трассируемости данных между бизнес-процессами и IT-сервисами.
- В статье почти не рассматриваются федеративные подходы вроде data mesh.
IT service model
- State описывает изменяемое состояние и жизненный цикл сервиса.
- Structure фиксирует связи сервисов и композицию компонентов.
- Port задает входные/выходные точки для интеграций и контрактов.
Для детального погружения в domain model и bounded contexts полезно держать рядом главу об Adaptive Enterprise Architecture.
Связующая логика между бизнесом и IT
- Domain objects рассматриваются как единица трассировки между бизнес-моделью и IT-реализацией.
- Bounded context предлагается использовать для выделения логических границ сервисов.
- Single Responsibility Principle применяется как критерий качества этих границ.
- Общий каталог capabilities помогает выявлять дубли и избыточность в enterprise-ландшафте.
Сильные стороны и ограничения
Что в подходе полезно
- Полезная попытка объединить язык enterprise architecture и практики DDD в одной рамке.
- Четкая структура из 7 моделей помогает не терять связь между стратегией, процессами и сервисами.
- Фокус на bounded context и capabilities дает практичную основу для декомпозиции систем.
- Подход может быть полезен для крупных организаций со сложным legacy-ландшафтом.
Где есть риски
- Многие блоки enterprise architecture даны слишком абстрактно и тяжело переводятся в конкретные инженерные решения.
- Первые три модели (strategy/organization/process) описаны поверхностно, из-за чего общая связка выглядит неравномерной.
- Data-model часть опирается на классический стек и почти не затрагивает современные федеративные практики.
- Без сильной внутренней дисциплины метод легко уходит в документацию ради документации.
Если знакомо ощущение «все слова понятны по отдельности, но не складываются в систему», хорошо передает настроение ироничный референс про «фирму, которая занимается ничем».
Практический чек-лист для команды
- Начинать не с полной enterprise-карты, а с одного критичного бизнес-потока.
- Сначала фиксировать subdomains и bounded contexts, затем проектировать capability components.
- Для каждого capability явно описывать data ownership, входные/выходные порты и SLA-сигналы.
- Каждую модель связывать с архитектурными решениями (ADR), чтобы описания влияли на delivery.
- Раз в квартал пересматривать карту capabilities и устранять дубли между системами.
Связанные главы
Cross-layer Enterprise Architecture Evaluation
Соседний paper про оценку TO-BE enterprise architecture через сквозные слои.
Modular Monolith: Is This the Trend in Software Architecture?
Разбор границ модулей и компромиссов декомпозиции на практике.
Adaptive Enterprise Architecture
Смежный взгляд на enterprise architecture как на непрерывный процесс адаптации.