5 min read

Microservices rules #5: Deliberative design

This is the second 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

3. Apply Team Topologies

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, part 3

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

Designing software is all about making decisions. An architecture is created by making a series of design decisions. Each decision solves a particular problem by choosing or creating a solution. The solution modifies the architecture by adding, modifying or deleting architectural elements and the relations between them. The resulting architecture is a composition of all the past design decisions. It’s essential, therefore, to use Microservices rule #5: a deliberative design process.

Miriam-Webster defines ‘deliberation’ as follows:

In other words, deliberative design involves thinking about how to solve a problem and carefully picking a solution.

In this article, I describe the 7 step deliberative design process. But first, let’s look at some unreliable ways to make design decisions.

This post is for paying subscribers only