3 Messages

The term microservices invites you to think in terms of services. You’ll naturally be drawn to ask, “What are the microservices in this system?” Resist that temptation. Microservice systems are powerful because they allow you to think in terms of messages. If you take a messages-first approach to your system design, you free yourself from premature implementation decisions. The intended behavior of the system can be described in terms of a language of messages, independent of the underlying microservices that generate and react to those messages.

3.1 Messages are first-class citizens

A messages-first approach is more useful than a services-first approach to system design. Messages are a direct expression of intent. Business requirements are expressed as the activities that should happen in the system. We’re traditionally taught to extract the nouns from business requirements, so that we can build objects. In practice objects as an abstraction are not found to be a good way to express requirements, because they are conceptually at a level below the requirements.

3.1.1 Synchronous and asynchronous

3.1.2 When to go synchronous

3.1.3 When to go asynchronous

3.1.4 Thinking distributed from day one

3.1.5 Tactics to limit failure

3.2 Case study: Sales tax rules

3.2.1 The wider context

3.3 Pattern matching

3.3.1 Sales tax: starting simple

3.3.2 Sales tax: handling categories

3.3.3 Sales tax: going global

3.3.4 Business requirements change, by definition

3.3.5 Pattern matching lowers the cost of refactoring

3.4 Transport independence

3.4.1 A useful fiction: the omnipotent observer

3.5 Message patterns

3.5.1 Core patterns: one message/two services

3.5.2 Core patterns: two messages/two services

3.5.3 Core patterns: one message/n services