Chris Richardson: Microservices Patterns

1. Escaping monolithic hell – výhody, nevýhody, o čem je kniha, jak popisuje vzory i potřeby a změny v organizaci
2. Decomposition strategies – co je architektura, architektonické styly, přístupy k rozkladu na microservices

Zajímavost – každá service může mít vlastní verzi třídy, vlastní doménový model:

A much better approach is to apply DDD and treat each service as a separate subdomain with its own domain model. This means that each of the services in the FTGO application that has anything to do with orders has its own domain model with its version of the Order class. A great example of the benefit of multiple domain models is the Delivery Service. Its view of an Order, shown in figure 2.11, is extremely simple: pickup address, pickup time, delivery address, and delivery time. Moreover, rather than call it an Order, the Delivery Service uses the more appropriate name of Delivery. (Domain Driven Design Str. 59)

3. Interprocess communication in a microservice architecture – přehled IPC, synchronní komunikace, asynchronní messaging.
4. Managing transactions with sagas – jak řešit transakce v distribuovaném světě, saga pattern, koordinace pomocí choreografie nebo orchestrace, řešení izolace
5. Designing business logic in a microservice architecture – jak rozvrhnout byznys logiku, vzory pro doménový model, DDD aggregate pattern, granularita, publikace doménových událostí

Zajímavost – modelový objekt by neměl publikovat události přímo, lepší je nechat ho předávat je publikační službě, nezatěžuje se tak jeho kód infrastrukturním voláním:

Conceptually, domain events are published by aggregates. An aggregate knows when its state changes and hence what event to publish. An aggregate could invoke a messaging API directly. The drawback of this approach is that because aggregates can’t use dependency injection, the messaging API would need to be passed around as a method argument. That would intertwine infrastructure concerns and business logic, which is extremely undesirable.

A better approach is to split responsibility between the aggregate and the service (or equivalent class) that invokes it. Services can use dependency injection to obtain a reference to the messaging API, easily publishing events. The aggregate generates the events whenever its state changes and returns them to the service. There are a couple of different ways an aggregate can return events back to the service. One option is for the return value of an aggregate method to include a list of events. (Str. 164)

6. Developing business logic with event sourcing – rozdíl proti klasické perzistenci, pravda je v událostech, přístupy pro zlepšení výkonu, implementace event store, interakce se ságami.

Zajímavost – jak si poradit se změnami „schématu“, tedy jak migrovat již existující události:

An event sourcing application can use a similar approach to handle non-backward compatible changes. But instead of migrating events to the new schema version in situ, event sourcing frameworks transform events when they’re loaded from the event store. A component commonly called an upcaster updates individual events from an old version to a newer version. As a result, the application code only ever deals with the current event schema. (Str. 199)

7. Implementing queries in a microservice architecture – API composition pattern, CQRS pattern
8. External API patterns – API gateway patterns a implementace (spíše „backend for frontend“ než infrastrukturní API GW)
9. Testing microservices: Part 1 – jak na testování, unit testy pro services (pro doménové objekty, ságy, doménové služby, event handlery)
10. Testing microservices: Part 2 – jak psát integrační testy, jak testy komponent a konečně jak testy end-to-end
11. Developing production-ready services – co ještě chybí pro produkční provoz? Bezpečnost, konfigurovatelnost, observabilita
12. Deploying microservices – a pak už konečně deployment na produkci. Ale jak? Prostředky zvoleného programovacího jazyka? Na virtuální stroj? Jako kontejner (ukázka s Kubernetes)? Jako serverless (ukázka s AWS)?
13. Refactoring to microservices – strategie na rozebírání monolitu, návrh spolupráce monolitu a škrtiče („strangler“), propojovací vrstva, rady na replikaci dat nebo vytvoření izolační vrstvy:

For example, Delayed Delivery Service has a Delivery entity with narrowly focused responsibilities, whereas the FTGO monolith has an Order entity with an excessive number of responsibilities. Because the two domain models are different, you must implement what DDD calls an anti-corruption layer (ACL) in order for the service to communicate with the monolith. The goal of an ACL is to prevent a legacy monolith’s domain model from polluting a service’s domain model. It’s a layer of code that translates between the different domain models. (Str. 446)

Kniha je opravdu doširoka rozkročená a díky tomu poslouží stejně dobře aplikačním architektům, vývojářům i všem, kdo chtějí mikroslužbám porozumět.

Odkazy: