Despite microservices being so hyped Eric Evans still believes there is tremendous value in them, probably giving us the best environment we have ever had for doing Domain-Driven Design (DDD), he stated in his keynote at this year’s DDD Exchange conference in London.
Iteration is for Evans the most important key to good design, and believes microservices to be the second attempt, after SOA, to get things right. One major difference is the extreme emphasize on isolation in microservices compared to earlier attempts with SOA where integration often was done through the database. Autonomy of teams working on different services and the DevOps movement with services built and deployed independently gives us boundaries and the ability to develop without being tangled-up with everything else. He also believes that the technology used has become much lighter, less coupled.
DDD benefits from microservices by getting real boundaries, and ideas like not sharing that the microservice community has converged on are what we want in a bounded context. He warns though that without a high level design view and strategy the mess that can be created with lots of services will look like the old monolithic tangled-together systems. Evans emphasizes that not all of a large system will be well designed and he thinks microservices can help here by creating isolation between services being well designed and others poorly designed and implemented.
For Evans the way a microservice is operated makes a good bounded context, at least on a first pass, making a one-to-one mapping between a service and a context. As services gets smaller and starts both coordinating and interacting with other small services in a very specific way then the bounded context may cover all these small services. His experience though is that we often make too big bounded contexts, the traditional monolith server application when becoming one context is way too big, and once again notes the importance of skilled people able to from a higher level find the domains and bounded contexts within a system.
Next year’s DDD Exchange is scheduled for 10th June 2016 and registration is open.
Community comments
A sample please
by Erik Gollot,
Re: A sample please
by Jan Stenberg,
Re: A sample please
by Erik Gollot,
Re: A sample please
by Erik Gollot,
A sample please
by Erik Gollot,
Your message is awaiting moderation. Thank you for participating in the discussion.
Interesting opinion but a sample could be interesting too. It's easy to say the service must have the right size but what are the criterium to define this size?
Re: A sample please
by Jan Stenberg,
Your message is awaiting moderation. Thank you for participating in the discussion.
As Eric says in the end of his presentation; There is no cook-book answer, the size of a bounded context covers a wide range, you need people who are good at figuring it out, and recognizing when they make a mistake and change course.
For myself, autonomy is an important aspect, a service should not be dependent on other services in order to respond.
Re: A sample please
by Erik Gollot,
Your message is awaiting moderation. Thank you for participating in the discussion.
Yes no magic bullet but some rules could help. And total independence is a dream. If you split a problem into smaller parts/components you have a good chance to relies on other components. A zero dependency is often achieve with big components which is not what we want.
Hul no silver bullet..
Re: A sample please
by Erik Gollot,
Your message is awaiting moderation. Thank you for participating in the discussion.
Why don't explore the nature of relationships between objects: simple association, agregation, composition ? And functional use cases ? All these elements can greatly help to take some decisions. But again independence is a dream if your context has any relationships with another context.