Question

With all the talk of Microservices with Domain Driven Design, I have been looking at two architectures, the Database-Centric Architecture and the Domain-Centric Architecture (Not to be confused with Domain Driven Design). Now in the Database-Centric Architecture, the database is the focal object we depend on. Without it, the application would not function. Using the Spring Framework as an example, we can now easily implement a whole Microservice ecosystem with all the magic Spring provides us. However, looking at a lot of Microservices diagrams it still looks a lot more Data-Centric to me as the database seems to be an important component that if it stopped working, the system would not function at all.

Microservice-Diagram

Looking at the diagram above, we easily break monoliths into independent services and we do manage to apply the Domain Driven Design within our Microservices. However, it still seems to me that we are still within the Database-Centric Architecture as our microservices would not function as expected without our databases. Also it seems that using a framework like Spring generally ties you into the MVC pattern (@Controller, @Service, @Repository) which to me is more Database-Centric rather than Domain-Centric.

Was it helpful?

Solution

Spring Framework is a framework that supports both architectures. It has features to make database-centric architecture easier to do, but it would be a misnomer to simply classify it that way.

There are several microservices built with Spring that don't use a database at all. You probably don't know about them because they are proprietary to, well, a domain.

You can find more blogs and articles about how to do data-centric things in Spring because there's a lot of tooling to make it easier, and because you can teach it in a way that is easy to abstract the principle from the details. Teaching domain-centric architecture is harder to abstract the principle, and it's less sexy because it requires less tooling.

I also think it is a misnomer to conflate MVC with data-centric design. MVC is a design pattern to separate a Model (which should be domain centric) from how services interact with it (Controller). Both of those are distinct from the View which in domain-centric services is usually 100% in the front end. Routing a URL to code in a class is a means of providing an understandable way of programming.

How you design your services is up to you. The URLs and Methods you respond to, and even how you authorize a user is up to you. Spring is simply a tool that can help you achieve those goals. It's a tool that is understood at some degree by most who develop Java based application. That means it's easier to find people who know how to use it and be productive sooner.

OTHER TIPS

You can turn any database-centric architecture into a domain-centric architecture by simply adding a layer of indirection.

Database Centric:

Database <--> Data Access Layer (DAL) <--> UI

Domain-Centric

Database <--> Data Access Layer (DAL) <--> Business Logic/Service Layer (BLL/SL) <--> UI

The DAL can be anything you want, including Spring. The BLL/SL communicates with the DAL using CRUD. The UI communicates with the BLL/SL using domain-specific methods.

Licensed under: CC-BY-SA with attribution
scroll top