5 Models

 

This chapter covers

  • Expressing components separately from their implementation in code.
  • Representing components and their relations (the architecture of the system) using the idea of model-as-code.
  • Coding a miniature system model.
  • Using the model to build, control and manage microservices.
  • Introduces the idea of the local monolith.
  • Understanding why diagrams are weak tools for system modeling.

Running microservice systems in practice requires more than just defining your requirements, mapping them onto messages, and mapping those messages onto services. Somehow you need to organize this structure and run it in production. It’s no good having a great component model if you need to read implementation code to understand what’s going on. You need to be able to think in terms of components. You need to be able to represent the system in a layer above the code.

The first edition of this book assumed you would use a combination of documentation, diagrams, conventions, and configuration, to represent your microservice system. This new chapter offers a better approach: model-as-code. In the same way that infrastructure-as-code has proven to be a useful technique, you can use the power of source code to keep your system under control and generate the various artifacts that you will need to run it in production.

5.1 Representing components

5.1.1 The layer above the code as code

5.1.2 Using the Model-as-Code representation

5.2 Taming microservices with models

5.2.1 The tale of the local monolith

5.2.2 Deploy distributed

5.2.3 Focus on the component relationships

5.3 Why UML (and others) Failed

5.3.1 Inherent disrespect

5.3.2 UML was impractical

5.3.3 The map fallacy

5.4 Summary