In this article, you’ll look at domain-centric architectures and the differences and connections between them and traditional data-centric architectures. The purpose of this article is to provide some additional information on the layered architecture of DDD in order to better understand its causes and effects.
As we all know, in the history of human science, there have been two discussions about the way the universe works, namely,geocentrism“And”Heliocentric theory“. Today we all know that the heliocentric theory is scientific, that the earth and the planets revolve around the sun, and probably even kindergarten children know this is basic common sense.A few hundred years ago, however, clinging to the heliocentric theory would have been punishable by death.
Our understanding of how the universe works has changed over the centuries just as our understanding of software architecture has changed over the decades. The heliocentric theory has replaced the geocentric theory, and the domain-centered architecture is gradually becoming mainstream.
Of course, the change of software architecture thinking is not exactly the same as the change of human cognition of the universe, after all, the “geocentric theory” is completely wrong. However, there is no absolute right or wrong in software architecture. Data-centric software architecture is not all bad. To be fair, it was born and popular for historical reasons, and it’s still useful today, but in some complex businesses, it has limitations.
In a data-centric architecture, the key is the user interface layer (see figure below), the business logic layer, and the data access layer that revolve around the database. As a result, the database is a veritable architecture hub. In this architecture, you don’t have to worry too much about the design of the business logic layer. In other words, no matter how the code at the business logic layer is stacked, the data falls into the library correctly. The scene may seem familiar, but it is. Don’t get me wrong, there’s no put-down. It’s just that if your business logic is complex and you’re using a data-centric architecture, you might want to rethink your architecture.
So how has the perspective of architecture changed from data-centric to domain-centric? There may be many reasons. Robert C. Martin (Uncle Bob), an industry veteran and author of Agile Software Development, once said:
The first concern of the architect is to make sure that the house is usable, it is not to ensure that the house is made of brick.
The uncle took the example of an architect building a house. What is the key to building a house for an architect? Is it brick or wood? Obviously not. The key thing about a house is that it’s usable. That’s fundamental. Why else would it be built? As for what materials to use and what style to choose, those are just details.
This example brings up two important concepts in architecture, Essential and Detail. Without a clear understanding of what is fundamental and what is just the details in a structure, and failing to put them in the right place, you are putting the cart before the horse. To the house, “usable” is fundamental, “brick”, “decorate” is a detail that it realizes however, still can use wood besides brick! Similarly, for a car, “reliable, safe” is its fundamental, as to whether it is electric or fuel, but it is different implementation.
In this case, the problem with data-centric software architecture is that it gets the basics wrong. In enterprise architecture, the “business logic” is fundamental, and the database, as a storage method, is just a specific detail that hosts the business data. It can be implemented in different ways, from relational databases to NoSQL and even file stores. It is important to note that this is not to say that data is not important, but that architecture is essentially a governance of complexity, not a management of data. Clearly, in most enterprise architectures, complex business logic is the focus of governance.
The result is a domain-centric Architecture.
In a domain-centric architecture, the domain is central to the architecture. This has the advantage of isolating domain complexity from technical complexity through a layered architecture, enabling independent governance of the two different types of complexity and focusing on the domain. In addition, good layering and decoupling makes the architecture more extensible and stable, as well as easier to maintain. Therefore, this architecture should be considered for complex business scenarios or products with long life cycles.
Of course, a domain-centric architecture is just an idea, and ideas inevitably have different implementations, and DDD is one of them. In a later article, you will see how the hexagonal and onion architectures implement domain-centric architectures.