Microservices rules #7: Design loosely design-time coupled services - part 2
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.
In part 1, I explained the concept of design-time coupling and the related concept of cohesion and described the benefits of a loosely coupled architecture.
In this article, I describe how to design loosely design-time coupled software.
Read more (This post is for paying subscribers only)
Premium content now available for paid subscribers at 
