How Domain-Driven Design Aids in the Planning of Microservices Architecture
Berke Sokhan, software developer with global IT consultancy firm ThoughtWorks, is arguing for a return to domain-driven design for services architecture.
He is worried now that the shine has worn off talking about domain-driven design (DDD), that DevOps will move too quickly onto the next bright idea without really leveraging the opportunities DDD brings to microservices architectures:
Because it is now getting older and the hype level is decreasing, many of us are forgetting that the DDD approach really helps understand the problem at hand and helps to design software towards a common understanding of the solution.
In application development, DDD defines problems as domains and subdomains. Independent steps and problem areas are then defined as bounded contexts. A common language is encouraged with definitions for entities, value objects and aggregate route rules.
Sokhan says it is very similar to microservices: the goal is to separate monolithic applications into multiple, stand-alone service applications. For those not wrestling with the technical debt of a legacy system, services can be created from the start using bounded contexts.
In monolithic, legacy systems, it is not uncommon to have integration of various services occur through the database.
But as more enterprises seek an agile way to develop new customer-facing products and to scale existing initiatives, architecture that integrates services via databases prevent horizontal scaling (because they need to add more application servers to grow) and end up needing to blur business logic by including it in some database models.
Sokhan says, as a result, “the evolution to a better architecture happens in the form of service integration of monolithic applications.”
But even with these separations business development friction emerges, as deep within the database is a spaghetti of code that has artificially coupled services tightly together. This is made worse by years of undocumented developer workarounds and patches that solved a specific problem at the time, but now seem to make no sense at all when stepping back and trying to figure out why an architecture is strung together the way it is.
Sokhan recommends that domain modeling be used to help expose these tightly coupled services. He suggests starting first by mapping the necessary application capabilities, a sort of imagining of the ideal scenario. Starting with documenting the existing application architecture too easily takes developers down a rabbit hole they never rise from again: by trying to go through the code to understand the application bounded contexts, a developer too easily gets “lost in the weeds.”
Sokhan uses an example of a credit/debit card domain model:
At its heart, a domain-driven design model helps an enterprise migrate to a microservices architecture by clarifying potential separation points and demonstrating how separate bounded contexts within the one domain can facilitate the development of multiple service applications. He also sees it as an instrumental tool in bringing business and engineering teams together. “Once transitioned to a microservices architecture [with the help of domain model], DDD and more granular services can work in synergy to support each other,” Sokhan posits.
Feature image: Old TriMet City Center map 15K by Jason McHuff. Licensed under CC BY-SA 2.0.
