Research on Enterprise Business Architecture Design Method Based on Domain-Driven Design (Рубрика Architecture)

Я продолжаю читать и делиться рассказами о whitepapers на тему архитектуры и сегодня речь про статью от ученых Huiwen Deng и Yan Zhao из China Aerospace Academy of Systems Science and Engineering, что в Пекине. В этой статье ребята решили объединить подходы из enterprise architecture с практиками DDD (Domain Driven Design) в попытке сблизить корпоративную архитектуру с IT архитектурой, чтобы это ни означало. Ну и все конечно во благо цифровой трансформации:)

Для определения бизнес архитектуры авторы вспоминают определение OMG (Object Management Group) из TOGAF (The Open Group Architecture Framework)

The formal blueprint outlining the enterprise’s governance structure, business capabilities, value streams; it clearly defines the enterprise’s governance structure along with its business capabilities, processes, and data Дальше авторы говорят, что именно она является основой цифровой трансформации и связывает стратегию корпорации с процессами и IT-системами. По факту, она служит неким "каркасом" для построения цифровых предприятий. Дальше авторы рассказывают базу про DDD, а точнее, что

• DDD помогает моделировать сложные бизнес-процессы через глубокое понимание домена.
• Для этого используются стратегические подходы: subdomains, bounded contexts

По мнению авторов DDD дополняет традиционные методы бизнес-архитектуры более детализированным подходом к сложным процессам. Авторы предлагают использовать метамодель, объединяющую стратегии, домены, данные и IT-сервисы. Авторы упоминают 7 моделей в своем подходе: strategy model, organization model, process model, domain model, capability model, data model, IT service model. Первые три модели из этого списка авторы пробегают галопом по Европам, а вот последние четыре разбирают подробнее

1. Domain model: модель состоит из стратегии домена, где определяются сабдомены, доменные объекты и доменные события. Про это подробнее рекомендую почитать книгу Влада Хононова "Learning DDD", про которую я уже рассказывал.
2. Capability model: здесь авторы говорят про базовые возможности и точки расширения, дизайн capability components, а также про solution design. Условно, надо определиться с базовыми компонентами и способами их расширения, а дальше из этих базовых компонентов собирать те решения, которые требуются бизнесу
3. Data model: здесь авторы говорят про модель данных и делают отсылки к классическим подходам ETL/ELT и DWH с data lake. Интересно, что авторы похоже не слышали пока про федерализацию данных и data mesh.
4. IT service model: здесь авторы говорят про state, structure и port. Условно у нас есть изменяемое состояние, сервисы и их взаимосвязи, а также входные и выходные точки.

Основной подхода авторов должны являться доменные объекты, что связывают бизнес и IT. Для определения логических границ IT-систем авторы предлагают использовать DDD и определять bounded context, используя single responsibility principle. А с точки зрения бизнес архитектуры выделение общих возможностей помогает бороться с дублями и избыточностью систем.

В общем и целом, мне этот whitepaper дался не легко - я легко читал части про DDD, а вот части про enterprise architecture рассыпались на части - у меня было ощущение, что все слова по отдельности я понимаю, но вот смысла в них общего не слишком много, примерно как в старом видео про "Фирму, которая занимается ничем". Возможно, это просто мое предвзятое отношение к бюрократическим и бумажным процессам, что любят ребята из The Open Group, что и придумали TOGAF, который как мне кажется не подходит технологическим компаниям:)

#Architecture #Software #DDD #SystemDesign #Whitepaper #Engineering