DDD, necessary but insufficient: physical design principles for microservices
architecting microservice architecture dark energy and dark matter loose couplingPublic workshops:
- Enabling DevOps and Team Topologies Through Architecture: Architecting for Fast Flow JNation, May - Coimbra, Portugal Learn more
- Designing microservices: responsibilities, APIs and collaborations DDD EU, June 2-3, Antwerp, Belgium Learn more
Contact me for information about consulting and training at your company.
This is a presentation I recently gave at DDD SoCal.
See below for the slides and video.
Abstract
When we design software using DDD, we primarily focus on creating models scoped by bounded contexts that define ubiquitous languages. We also structure the models and the elements they contain to be loosely coupled and highly cohesive. However, while (logical) design techniques such as DDD domain modeling concepts, loose coupling and high cohesion are essential for creating good software, they are insufficient when designing a microservice architecture. In particular, we must also consider other more physical constraints including team size; team, process and transaction boundaries; and the cost of communication over a network.
In this talk, I describe a set of physical design principles for organizing subdomains into microservices. You will learn about both principles that encourage finer-grained decomposition into services as well as those that discourage decomposition. I describe how to apply those principles to design a microservice architecture.
Slides
Video
Need help adopting microservices?
I provide consulting and training.
Premium content now available for paid subscribers at 
