Introduction
Domain-centric architecture is an up-and-coming topic when deciding how to structure new applications. A lot of todays applications are centered around a database and not a domain, which is good in some cases but can get rather complex in other cases. As a lot of applications work like a basic CRUD-application, the database at the center usually doesn’t hurt. But even simple CRUD-apps could benefit from putting the domain at the center instead of the database.
What is a domain?
The domain, when talking in terms of software engineering, defines the part of the business that the software will be used in. There is no specific definition of how a business can be split into domains, but it should rather be a process between IT and business to define which domains make sense in their business. To make an example, a webshop could either be one domain, the shop itself, or it could be split up into multiple domains, namely products, logistics and warranty. Without knowing the exact business you cannot decide which of the two makes more sense. So before starting with any design decicions, both parties have to define with which domains it will be working.
Database-centric architecture
The database-centric architecture is what most people get taught or learn first. It consists of the 3 layers Data Access, Business Logic and Presentation / UI with a database at the center. As most applications are simple CRUD-applications, it makes sense to use an architecture like that as it supports most CRUD use-cases easily, has a short setup-time and you can get some first results rather quickly.
The problem with this approach is that it’s hard to depict complex domains easily in software. All your decicions are directly or indirectly influenced by the database, because the database is at the center of the architecture, all layers depend on it and are built around it. If you ever want to change the database, you have impact on all layers because you change the centerpoint of the whole architecture.
Over the years this approach has come to it’s limits because it is dictated by a technical aspect of the system, the database, and not by the business that is driving it.
Put the domain at the center
To overcome the problems that a database-centric architecture brings, the domain of the business can be put at the center of the architecture, which gives you a domain-centric architecture. With this new approach, all layers depend on the domain, the core of the business, instead of an implementation detail like a database. Your whole system now has the business as it’s centerpoint and evolves around that. Technical implementations like databases, caches, queues, etc. are kept on the outside of the architecture and depend on the domain, meaning you implement the database based on the domain, and not the other way around.
When designing such an application system, you can first work out, together with the business, exactly what the domain is, which functionalities and use-cases it has to contain and how it should behave. With a good domain design, you have a very close image in software of how the business is working. After that the layers on top of the domain can be built. Because the centerpoint, the domain, was designed with the business in mind and all future layers depend on it, these future layers will also reflect the functionality of the business. If you ever want to change an implementation, use a new database or move to a new cloud-provider, you can now easily do so by replacing an outer layer instead of the centerpoint of the whole application, saving you money and ressources.
Conclusion
The advantages of putting the domain at the center is definitely that you write software with the business in mind, and not technologies. You can easily move to newer technologies or clean up legacy software because you keep all implementation details very far away from the center of the architecture. The core should rarely change, as it represents the business use-cases. As soon as it changes, all depending layers have to be changes as well, which makes sense as new business functionality has to be passed through all layers so the UI and client can use it.
A big disadvantage of this is the learing curve for developers as they usually learn database-centric architecture first. The whole thought-process has to be changed to put the domain at the center. This architecture also brings added complexity and potentially higher costs upfront, which should be worth it in the long run as the architecture will be more flexible with the domain at the center.