Microservice Pattern

It also provides an overview of the microservice architecture pattern language, which is the organizing theme for most of the book. As you go through these chapters, you'll learn about different aspects of the microservices architecture.

The slow march toward monolithic hell

Easy to test: The developers wrote end-to-end tests that launched the application, called the REST API, and tested the UI with Selenium. Another problem with the FTGO application is that implementing changes in production is a long and painful process.

Figure 1.1 The FTGO application has a hexagonal architecture. It consists of business logic surrounded by adapters that implement UIs and interface with external systems, such as mobile applications and cloud services for payments, messaging, and email.

Why this book is relevant to you

They often have to maintain an application written with an increasingly outdated technology stack. As a result, the main parts of the application are written with increasingly outdated frameworks.

What you’ll learn in this book

The Spring framework has continued to evolve while being backwards compatible, so in theory FTGO could potentially upgrade. Unfortunately, the FTGO app uses versions of frameworks that are not compatible with newer versions of Spring.

Microservice architecture to the rescue

The router before the instances uses a request attribute to route it to the appropriate instance. The high-level definition of microservices architecture (microservices) is an architectural style that functionally decomposes an application into a set of services.

Figure 1.3 The scale cube defines three separate ways to scale an application: X-axis scaling load balances requests across multiple, identical instances; Z-axis scaling routes requests based on an attribute of the request; Y-axis functionally decomposes

Benefits and drawbacks of the microservice architecture

The most important advantage of microservices architecture is that it enables continuous delivery and deployment of large, complex applications. Another problem with using a microservices architecture is that developers have to deal with the added complexity of creating a distributed system.

Figure 1.8 The microservices-based FTGO application consists of a set of loosely coupled services

The Microservice architecture pattern language

We – the software development community – need to overcome our emotional nature and find a better way to discuss and apply technology. Problems – The new problems that have been introduced by applying the pattern. The resulting context provides a more complete and less biased view of the solution, enabling better design decisions.

Figure 1.9 The visual representation of different types of relationships between the patterns: a successor pattern solves a problem created by applying the predecessor pattern; two or more patterns can be alternative solutions to the same problem; one p

Beyond microservices: Process and organization

The microservices architecture accelerates the speed of software development by enabling small, independent teams to work in parallel. The microservice architecture pattern language is a collection of patterns that help you build an application using the microservice architecture.

What is the microservice architecture exactly?

It is the decomposition into parts and the relationships between those parts that determine the possibilities of the application. Instead of the presentation layer, the application has one or more inbound adapters that handle outside requests by calling the business logic. An important feature and advantage of this architecture is that the business logic is not dependent on the adapters.

A port defines a set of operations and represents the way business logic interacts with what's outside. An important advantage of the hexagonal architectural style is that it separates the business logic from the presentation and data access logic in the adapters.

Figure 2.1 The 4+1 view model describes an application’s architecture using four views, along with scenarios that show how the elements within each view collaborate to handle requests.

Defining an application’s microservice architecture

The second step is to define the system operations, which are defined in terms of the domain model. The geosearch component of the query consists of finding all points—restaurants—that are near a location—the delivery address. The behavior of each system operation is described in terms of the domain model.

The domain model is closely reflected in the design and implementation of the application. For more information on SRP, CCP, and the other OOD principles, see the article "The Principles of Object Oriented Design" on Bob Martin's website (http://butunclebob.com/ArticleS.UncleBob .PrinciplesOfOod).

Figure 2.6 System operations are derived from the application’s requirements using a two-step process

Overview of interprocess communication in a microservice architecture

Synchronous - The client waits for a timely response from the service and can even block while it waits. Asynchronous - The client does not block and the response, if any, is not necessarily sent immediately. For example, if you are using messaging, the API consists of message channels, message types, and message formats.

If you use HTTP, the API consists of the URLs, the HTTP verbs, and the request and response formats. If you are using a statically typed language, the compiler helps by providing a list of compilation errors.

Table 3.1 The various interaction styles can be characterized in two dimensions: one-to-one vs one-to- one-to-many and synchronous vs asynchronous.

Communicating using the synchronous Remote procedure invocation pattern

Tier 3—The design of a Tier 3 service is based on the terribly named HATEOAS (Hypertext As The Engine Of Application State) principle. One way to implement service discovery is to have application services and their clients interact with the service registry. A service client invokes a service by first querying the service registry to obtain a list of service instances.

When a service client wants to invoke a service, it queries the service registry to obtain a list of the service's instances. The router queries the service registry and load balances requests about the available service instances.

Figure 3.1 The client’s business logic invokes an interface that is implemented by an RPI proxy adapter class

Communicating using the Asynchronous messaging pattern

Eliminate the possibility of the message broker being a performance bottleneck or a single point of failure. A sender writes the message to the message broker, and the message broker delivers it to the receiver. The traditional solution is to use a distributed transaction that spans the database and the message broker.

There are several different ways to move messages from the database to the message broker. A transaction log miner can read the transaction log and publish any changes as a message to the message broker.

Figure 3.7 The business logic in the sender invokes a sending port interface, which is implemented by a message sender adapter

Using asynchronous messaging to improve availability

2 Order service retrieves consumer information by making an HTTP GET /consumer/id request to consumer service. For example, the availability of the Order Service would be reduced if it sent a message to the Consumer Service via a message broker and then waited for a response. For example, Order Service could maintain a replica of data owned by Consumer Service and Restaurant Service.

7 Order service receives Consumer Validated and Order Details Validated and changes the state of the order to VALIDATED. Order Service changes the state of the order to VALIDATED when it receives the second message.

Transaction management in a microservice architecture

However, due to the issues mentioned so far, distributed transactions are not a viable technology for modern applications. Later, in Section 4.2, you will see how coordination of the steps is implemented using asynchronous messaging. An important advantage of asynchronous messaging is that it ensures that all steps in a saga are executed even if one or more of the saga's participants are temporarily unavailable.

This means, for example, that the FTGO app must explicitly if the credit card authorization fails in the fourth step of the Order Creation Saga. To see how offset transactions are used, imagine a scenario where a consumer's credit card authorization fails.

Figure 4.1 The createOrder() operation updates data in several services. It must use a mechanism to maintain data consistency across those services.

Coordinating sagas

Cyclic dependencies between services - Saga participants subscribe to each other's events, often creating cyclic dependencies. However, if the consumer verification failed, the saga rejects the order and goes to the Rejecting Order state. Order service processes the participant's response message by updating the state of the saga orchestrator and sending a command message to the next saga participant.

Improves separation of concerns and simplifies business logic – the saga coordination logic is located in the saga orchestrator. The order class has no intermediate states corresponding to the saga stages.

Figure 4.4 shows the design of the choreography-based version of the Create Order Saga

Handling the lack of isolation

In this scenario, the Create Order Saga ignores and overwrites the Cancel Order Saga update. In this scenario, the Create Order Saga performs a dirty read of available credit, allowing the consumer to place an order that exceeds their credit limit. It is the developer's responsibility to write sagas in a way that prevents anomalies or minimizes their impact on the business.

In that scenario, Saga Create Order performed a dirty read of available credit and created one. Saga Create Order can use this countermeasure to handle the scenario where the Order is canceled while it is in the approval process.

Figure 4.8 A saga consists of three different types of transactions: compensatable transactions, which can be rolled back, so have a compensating transaction, a pivot transaction, which is the saga’s go/no-go point, and retriable transactions, which are

The design of the Order Service and the Create Order Saga

It executes the saga state machine and exchanges messages with saga participants using the Eventuate Tram framework. The heart of the Create-OrderSaga class is the saga definition shown in the following listing. The SagaManager handles persisting a saga, sending the command messages it generates, subscribing to response messages, and invoking the saga to handle responses.

The SagaManager handles the persistence of a saga, sends the command messages it generates, subscribes to response messages, and invokes the saga. Listing 4.7 The OrderServiceConfiguration is a Spring @Configuration class that defines the Spring @Beans for the OrderService.

Figure 4.10 OrderService creates and updates Orders , invokes the OrderRepository to persist Orders , and creates sagas, including the CreateOrderSaga .

Business logic organization patterns

But using an object-oriented language does not guarantee that the business logic has an object-oriented design. Organize the business logic as a collection of procedural transaction scripts, one for each type of request. In an object-oriented design, the business logic consists of an object model, a network of relatively small classes.

Organize the business logic as an object model consisting of classes with state and behavior. Service: An object that implements business logic that does not belong in an entity or a value object.

Figure 5.1 The Order Service has a hexagonal architecture. It consists of the business logic and one or more adapters that interface with external applications and other services.

Designing a domain model using the DDD aggregate pattern

For example, let's look at how to ensure minimum order fulfillment when multiple consumers participate in order creation. From the application perspective, both consumers retrieve the order and its items from the database. For example, instead of directly updating line item quantities, the customer must call a method at the root of the order aggregate that enforces invariants such as the minimum order amount.

For example, an application can only update the rows that correspond to the Order object and the updated OrderLineItem. The business logic consists of the order aggregate, the OrderService service class, the OrderRepository, and one or more sagas.

Figure 5.5 shows the Order aggregate and its boundary. An Order aggregate consists of an Order entity, one or more OrderLineItem value objects, and other value objects such as a delivery Address and PaymentInformation.

Publishing domain events

We'll take a look at the code, but first let's examine a concept closely related to aggregates: domain events. The disadvantage of an event consumer making service requests for an aggregate is that it incurs service request overhead. Domain events are represented by orange sticky notes arranged in a rough timeline on the modeling surface.

It defines several overloaded publish() methods that take the aggregate type and ID as parameters, along with a list of domain events. This is a generic class that has two type parameters, A, the aggregate type, and E, the tag interface type for the domain events.

Figure 5.10 shows the result of an event-storming workshop. In just a couple of hours, the participants identified numerous domain events, commands, and aggregates

Kitchen Service business logic

Now that we've looked at aggregates and domain events, it's time to consider some examples of business logic implemented with aggregates. As described in Chapter 2, when we talk about the concept of bounded context, this aggregate represents the restaurant kitchen's view of the order. It does not contain information about the consumer, such as their identity, delivery information or payment details.

Let's first look at the structure of this class and then we'll examine its methods.