I recently had one of these special AHA-moments in a workshop held by Udi Dahan, CEO of Particular. In his example he was using the classic entity of a customer.
To realise microservices means cutting functionality in a clean way and to transfer it into separate pillars (or silos). Each silo has to have the responsibility over it’s own data, on which it builds the respective business processes. So far, so good. But how can we realise this for our typical customer, who’s model is shown in the screenshot? Different properties are needed or changed by different microservices.
If the same entity is used in all pillars, there needs to be a respective synchronisation between all microservices. This results in a considerable impact on scalability and performance. In an application with lots of parallel changes of an entitiy the failing of the business processes will increase – or lead to inconsistencies in the worst case.
conventional entity of a customer
Udi suggests the following modelling
Customer is modelled with independent entities
To identify which data belongs together, Udi suggests an interesting approach:
Ask the operating department if changing a property has a consequence for another property.
Would changing the last name of customer have an influence on the price calculation? Or on the way of marketing?
Now we need to solve the problem of aggregation, for example if I want to show different data from different microservices in my view. In a classic approach we would have a table with following columns:
| ID_Customer | ID_MasterData | ID_Marketing | ID_Pricing |
This leads to the following two problems:
- The table needs to be extended if a new microservice is added
- If a microservice covers the same functionality in the form of data, you would have to add multiple columns for each microservice and allow NULL values as well
An example for the second point could be a microservice which covers the matter of payment methods. In the beginning you could only use credit cards and debit charges. Then Paypal. Bitcoin soon after. The microservice would have different tables on which the respective data for the payment method would be stored. In the aggregated table shown above it would be necessary to fill a separate column for each payment method the customer is using. If he doesn’t use it, a NULL value would be written. As you can see: This sucks.
Another approach is much more convenient for this. Which one this is and how it’s realised technically you can find on the GitHub repository of Particular.
) das DRY-Prinzip kennen.
Uli Armbruster 