book

Microservices Patterns

by Chris Richardson

November 2018

Intermediate to advanced

520 pages

16h 20m

English

Manning Publications

Read now

Unlock full access

List of Patterns
Chris Richardson
PrefaceAcknowledgmentsAbout this bookWho should read this bookRoadmapAbout the codeBook forumOther online resourcesAbout the authorAbout the cover illustration
1.1. The slow march toward monolithic hell1.1.1. The architecture of the FTGO application1.1.2. The benefits of the monolithic architecture1.1.3. Living in monolithic hell1.2. Why this book is relevant to you1.3. What you’ll learn in this book1.4. Microservice architecture to the rescue1.4.1. Scale cube and microservices1.4.2. Microservices as a form of modularity1.4.3. Each service has its own database1.4.4. The FTGO microservice architecture1.4.5. Comparing the microservice architecture and SOA1.5. Benefits and drawbacks of the microservice architecture1.5.1. Benefits of the microservice architecture1.5.2. Drawbacks of the microservice architecture1.6. The Microservice architecture pattern language1.6.1. Microservice architecture is not a silver bullet1.6.2. Patterns and pattern languages1.6.3. Overview of the Microservice architecture pattern language1.7. Beyond microservices: Process and organization1.7.1. Software development and delivery organization1.7.2. Software development and delivery process1.7.3. The human side of adopting microservicesSummary
2.1. What is the microservice architecture exactly?2.1.1. What is software architecture and why does it matter?2.1.2. Overview of architectural styles2.1.3. The microservice architecture is an architectural style2.2. Defining an application’s microservice architecture2.2.1. Identifying the system operations2.2.2. Defining services by applying the Decompose by business capability pattern2.2.3. Defining services by applying the Decompose by sub-domain pattern2.2.4. Decomposition guidelines2.2.5. Obstacles to decomposing an application into services2.2.6. Defining service APIsSummary
3.1. Overview of interprocess communication in a microservice architecture3.1.1. Interaction styles3.1.2. Defining APIs in a microservice architecture3.1.3. Evolving APIs3.1.4. Message formats3.2. Communicating using the synchronous Remote procedure invocation pattern3.2.1. Using REST3.2.2. Using gRPC3.2.3. Handling partial failure using the Circuit breaker pattern3.2.4. Using service discovery3.3. Communicating using the Asynchronous messaging pattern3.3.1. Overview of messaging3.3.2. Implementing the interaction styles using messaging3.3.3. Creating an API specification for a messaging-based service API3.3.4. Using a message broker3.3.5. Competing receivers and message ordering3.3.6. Handling duplicate messages3.3.7. Transactional messaging3.3.8. Libraries and frameworks for messaging3.4. Using asynchronous messaging to improve availability3.4.1. Synchronous communication reduces availability3.4.2. Eliminating synchronous interactionSummary

4.1. Transaction management in a microservice architecture4.1.1. The need for distributed transactions in a microservice architecture4.1.2. The trouble with distributed transactions4.1.3. Using the Saga pattern to maintain data consistency4.2. Coordinating sagas4.2.1. Choreography-based sagas4.2.2. Orchestration-based sagas4.3. Handling the lack of isolation4.3.1. Overview of anomalies4.3.2. Countermeasures for handling the lack of isolation4.4. The design of the Order Service and the Create Order Saga4.4.1. The OrderService class4.4.2. The implementation of the Create Order Saga4.4.3. The OrderCommandHandlers class4.4.4. The OrderServiceConfiguration classSummary
5.1. Business logic organization patterns5.1.1. Designing business logic using the Transaction script pattern5.1.2. Designing business logic using the Domain model pattern5.1.3. About Domain-driven design5.2. Designing a domain model using the DDD aggregate pattern5.2.1. The problem with fuzzy boundaries5.2.2. Aggregates have explicit boundaries5.2.3. Aggregate rules5.2.4. Aggregate granularity5.2.5. Designing business logic with aggregates5.3. Publishing domain events5.3.1. Why publish change events?5.3.2. What is a domain event?5.3.3. Event enrichment5.3.4. Identifying domain events5.3.5. Generating and publishing domain events5.3.6. Consuming domain events5.4. Kitchen Service business logic5.4.1. The Ticket aggregate5.5. Order Service business logic5.5.1. The Order Aggregate5.5.2. The OrderService classSummary
6.1. Developing business logic using event sourcing6.1.1. The trouble with traditional persistence6.1.2. Overview of event sourcing6.1.3. Handling concurrent updates using optimistic locking6.1.4. Event sourcing and publishing events6.1.5. Using snapshots to improve performance6.1.6. Idempotent message processing6.1.7. Evolving domain events6.1.8. Benefits of event sourcing6.1.9. Drawbacks of event sourcing6.2. Implementing an event store6.2.1. How the Eventuate Local event store works6.2.2. The Eventuate client framework for Java6.3. Using sagas and event sourcing together6.3.1. Implementing choreography-based sagas using event sourcing6.3.2. Creating an orchestration-based saga6.3.3. Implementing an event sourcing-based saga participant6.3.4. Implementing saga orchestrators using event sourcingSummary
7.1. Querying using the API composition pattern7.1.1. The findOrder() query operation7.1.2. Overview of the API composition pattern7.1.3. Implementing the findOrder() query operation using the API composition pattern7.1.4. API composition design issues7.1.5. The benefits and drawbacks of the API composition pattern7.2. Using the CQRS pattern7.2.1. Motivations for using CQRS7.2.2. Overview of CQRS7.2.3. The benefits of CQRS7.2.4. The drawbacks of CQRS7.3. Designing CQRS views7.3.1. Choosing a view datastore7.3.2. Data access module design7.3.3. Adding and updating CQRS views7.4. Implementing a CQRS view with AWS DynamoDB7.4.1. The OrderHistoryEventHandlers module7.4.2. Data modeling and query design with DynamoDB7.4.3. The OrderHistoryDaoDynamoDb classSummary
8.1. External API design issues8.1.1. API design issues for the FTGO mobile client8.1.2. API design issues for other kinds of clients8.2. The API gateway pattern8.2.1. Overview of the API gateway pattern8.2.2. Benefits and drawbacks of an API gateway8.2.3. Netflix as an example of an API gateway8.2.4. API gateway design issues8.3. Implementing an API gateway8.3.1. Using an off-the-shelf API gateway product/service8.3.2. Developing your own API gateway8.3.3. Implementing an API gateway using GraphQLSummary
9.1. Testing strategies for microservice architectures9.1.1. Overview of testing9.1.2. The challenge of testing microservices9.1.3. The deployment pipeline9.2. Writing unit tests for a service9.2.1. Developing unit tests for entities9.2.2. Writing unit tests for value objects9.2.3. Developing unit tests for sagas9.2.4. Writing unit tests for domain services9.2.5. Developing unit tests for controllers9.2.6. Writing unit tests for event and message handlersSummary
10.1. Writing integration tests10.1.1. Persistence integration tests10.1.2. Integration testing REST-based request/response style interactions10.1.3. Integration testing publish/subscribe-style interactions10.1.4. Integration contract tests for asynchronous request/response interactions10.2. Developing component tests10.2.1. Defining acceptance tests10.2.2. Writing acceptance tests using Gherkin10.2.3. Designing component tests10.2.4. Writing component tests for the FTGO Order Service10.3. Writing end-to-end tests10.3.1. Designing end-to-end tests10.3.2. Writing end-to-end tests10.3.3. Running end-to-end testsSummary
11.1. Developing secure services11.1.1. Overview of security in a traditional monolithic application11.1.2. Implementing security in a microservice architecture11.2. Designing configurable services11.2.1. Using push-based externalized configuration11.2.2. Using pull-based externalized configuration11.3. Designing observable services11.3.1. Using the Health check API pattern11.3.2. Applying the Log aggregation pattern11.3.3. Using the Distributed tracing pattern11.3.4. Applying the Application metrics pattern11.3.5. Using the Exception tracking pattern11.3.6. Applying the Audit logging pattern11.4. Developing services using the Microservice chassis pattern11.4.1. Using a microservice chassis11.4.2. From microservice chassis to service meshSummary
12.1. Deploying services using the Language-specific packaging format pattern12.1.1. Benefits of the Service as a language-specific package pattern12.1.2. Drawbacks of the Service as a language-specific package pattern12.2. Deploying services using the Service as a virtual machine pattern12.2.1. The benefits of deploying services as VMs12.2.2. The drawbacks of deploying services as VMs12.3. Deploying services using the Service as a container pattern12.3.1. Deploying services using Docker12.3.2. Benefits of deploying services as containers12.3.3. Drawbacks of deploying services as containers12.4. Deploying the FTGO application with Kubernetes12.4.1. Overview of Kubernetes12.4.2. Deploying the Restaurant service on Kubernetes12.4.3. Deploying the API gateway12.4.4. Zero-downtime deployments12.4.5. Using a service mesh to separate deployment from release12.5. Deploying services using the Serverless deployment pattern12.5.1. Overview of serverless deployment with AWS Lambda12.5.2. Developing a lambda function12.5.3. Invoking lambda functions12.5.4. Benefits of using lambda functions12.5.5. Drawbacks of using lambda functions12.6. Deploying a RESTful service using AWS Lambda and AWS Gateway12.6.1. The design of the AWS Lambda version of Restaurant Service12.6.2. Packaging the service as ZIP file12.6.3. Deploying lambda functions using the Serverless frameworkSummary
13.1. Overview of refactoring to microservices13.1.1. Why refactor a monolith?13.1.2. Strangling the monolith13.2. Strategies for refactoring a monolith to microservices13.2.1. Implement new features as services13.2.2. Separate presentation tier from the backend13.2.3. Extract business capabilities into services13.3. Designing how the service and the monolith collaborate13.3.1. Designing the integration glue13.3.2. Maintaining data consistency across a service and a monolith13.3.3. Handling authentication and authorization13.4. Implementing a new feature as a service: handling misdelivered orders13.4.1. The design of Delayed Delivery Service13.4.2. Designing the integration glue for Delayed Delivery Service13.5. Breaking apart the monolith: extracting delivery management13.5.1. Overview of existing delivery management functionality13.5.2. Overview of Delivery Service13.5.3. Designing the Delivery Service domain model13.5.4. The design of the Delivery Service integration glue13.5.5. Changing the FTGO monolith to interact with Delivery ServiceSummary