---
title: How to model micro services?
description: How to model micro services?
tags: micro-service,bookclub
GA: UA-206161787-1
lang: en
---

###### tags: `Micro-service` `bookclub`

# Charpter 3 - How to Model Services

## What Makes a Good Service?

### Loose Coupling
> When a service are loosely coupled, a change to one service should not require a change to another.

> A loosely coupled service knows as little as it needs to about the services with which it collaborates

### High Cohesion
> We want related behavior to sit together, and unrelated behavior to sit elsewhere.

> To change behavior, we want to change them in one place and release them as a whole as soon as possible.

### Bounded Context
> Any given domain consists of multiple `bounded contexts`, and residing within each are things/models that may or may not need to share with outside world.

#### Example - MusicCorp
`Bounded Context`:
1. Warehouse department
* External: `inventory reports`.
* Internal: `forklift`, `trucks`.
2. Finance department
* External: `pay slips`.
* Internal: `calculators`.


> Even the `stock item` is a shared model by Finance and Warehouse, we don't need to blindly expose everything about the stock item. In other words, there could an internal (warehouse)/external (finance) representation of `stock item`.

### Modules and Services
> A project often begins with using modules within process boundary to keep related code together. These modular boundaries then become excellent candidates for microservices.

### Premature Decomposition
> Prematurely decomposing a system into microservices can be costly, especially if you are new to the domain. In many ways, having and existing codebase you want to decompose into microservices is much easier than trying to go to microservices from the beginning.

### Business Capabilities
> When you start to think about the bounded contexts that exist in your organization, you should be thinking not in terms of data that is shared, but about the capabilities those contexts provides the rest of the domain.
>
> So ask first "What does this context do?", and then "So what data does it need to do that?"

### Turtles All the Way Down
> Bounded contexts can in turn contain further bounded contexts. Think in large and high-level first and then break it down later. Sometimes, you could even decide to pop up the nested bounded contexts to an upper level.
>
> Whether you choose the nested approach over the full separation approach shoudl be based on your organizational structure.
>
> One potential benefit of the nested approach is to simplify testing so that we don't need to stub each service.


### Communications in Terms of Business Concepts
> The implementation changes are often driven by business. The modeling of your software after your business domain shouldn't stop at the idea of bounded contexts. In other words, the same terms and ideas that are shared between parts of your organization should be reflected in your interfaces.

### The Technical Boundary
> Making decisions to model service boundaries along technical seams isn't always wrong but this should be the secondary driver.