Research on Enterprise Business Architecture Design Method Based on Domain-Driven Design (Category Architecture)

I continue to read and share stories about whitepapers on the subject of architecture and today I'm talking about whitepapers. article Huiwen Deng and Yan Zhao from China Aerospace Academy of Systems Science and Engineering in Beijing. In this article, the guys decided to combine approaches from enterprise architecture with DDD practices. (Domain Driven Design) In an effort to bring corporate architecture closer to IT architecture, whatever that means. This is for the benefit of digital transformation:)

To define business architecture, the authors recall the definition of 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 Further, the authors say that it is the basis of digital transformation and connects the strategy of the corporation with processes and IT systems. In fact, it serves as a framework for building digital enterprises. Next, the authors tell the database about DDD, or rather, that DDD helps model complex business processes through a deep understanding of the domain. Strategic approaches: subdomains, bounded contexts

According to the authors, DDD complements traditional methods of business architecture with a more detailed approach to complex processes. The authors suggest using a metamodel that combines strategies, domains, data and IT services. The authors mention 7 Models in their approach: strategy model, organization model, process model, domain model, capability model, data model, IT service model. The first three models from this list are galloped around Europe, but the last four are disassembled in more detail.

1. Domain modelThe model consists of a domain strategy where subdomains, domain objects and domain events are defined. I recommend reading more about this book by Vlad Hononov “Learning DDD”, about which I have already read. told.
2. Capability model: here the authors talk about basic features and expansion points, design capability components, as well as solution design. Conventionally, it is necessary to determine the basic components and ways to expand them, and then from these basic components to collect those solutions that are required by business.
3. Data model: here the authors talk about the data model and make references to the classical approaches of ETL/ELT and DWH with data lake. Interestingly, the authors do not seem to have heard about the federalization of data and data mesh.
4. IT service modelHere the authors talk about state, structure and port. Conventionally, we have a variable state, services and their relationships, as well as input and output points.

The main approach of the authors should be domain objects that connect business and IT. To determine the logical boundaries of IT-systems, the authors propose to use DDD and define bounded context using the single responsibility principle. And from the point of view of business architecture, highlighting common features helps to combat duplicates and redundancy of systems.

In general, this whitepaper was not easy for me - I easily read the parts about DDD, but the parts about enterprise architecture fell apart - I had the feeling that all the words separately I understand, but here is the meaning in them is not too much, about the old video about "DDDD".A company that does nothing." Perhaps it's just my bias against bureaucratic and paper processes, which is what the Open Group guys love, which is what TOGAF came up with, which I don't think is right for tech companies:)

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