Microservices rules #7: Design loosely design-time coupled services - part 1
architecting design-time coupling microservices rulesPublic workshops: Designing microservices: responsibilities, APIs and collaborations:
- Explore DDD, April 14-15, Denver Learn more
- DDD EU, June 2-3, Antwerp, Belgium Learn more
This is another article in the series about microservices rules: what good looks like, which are a set of principles and practices for using microservices effectively. The articles in the series are:
1. Practice continuous delivery/deployment
2. Implement fast, automated deployment pipelines
4. Provide a great developer experience (DevEx)
5. Use a deliberative design process
6. Design independently deployable services
7. Design loosely coupled services - part 1, part 2
8. Design testable services
9. Develop observable services
10. Big/risky change => smaller/safer and (ideally easily) reversible changes - part 1 - incremental architecture modernization, part 2 - continuous deployment, part 3 - canary releases, part 4 - incrementally migrating users, part 5 - smaller user stories
11.Track and improve software metrics and KPIs
Microservices rules #7 is design loosely design-time coupled services. Loose design-time coupling is a defining characteristic of the microservice architecture. Many of the benefits of the microservice architecture are due to loose design-time coupling. But more generally, loose design-time coupling is an essential property of well-designed software, not just microservices.
In this article, I explain the concept of design-time coupling and the related concept of cohesion. You will learn about the benefits of loose design-time coupling. In a follow up article, I will describe how to design loosely design-time coupled software. I also discuss how to detect tight design-time coupling. Let’s start by looking at how a key goal of software design is minimizing design-time coupling and maximizing cohesion.
Premium content now available for paid subscribers at 
