Decomposition strategy

Services are organized around business concerns rather than technical concerns

What is a service?

• A service is a standalone, indepdently deploydable software component that implements some useful functionality

• A service has an API that provide its clients access to its functionality

• There are two types of operations:

  • Commands: such as createOrder()
  • Queries: findByOrderID()

• A service also publishes events, such as Order Created, which are consumed by its clients

The role of shared library

• You might be tempted to also use shared libraries in microservice architecture. On the surface, it looks like a good way to reduce code duplication in your services. But you need to ensure that you don’t accidentally intro- duce coupling between your services.
• You should strive to use libraries for functionality that’s unlikely to change

Define an application's microservice architecture

3 steps:

• Step 1: Identify system operations
• Step 2: Identify services
• Step 3: Define service APIs and collaborations

Identify the system operations

• First step: Create a high-level domain model which is derived from the nouns of the user stories.
• Second step: Define the system operations which are mostly from the verbs

Create a high-lvel domain model

Stories:

• PlaceOrder story

Given a consumer

And a restaurant

And a delivery address/time that can be served by that restaurant

And an order total that meets the restaurant's order minimum

When the consumer places an order for the restaurant

Then consumer's credit card is authorized

And an order is created in the PENDING_ACCEPTANCE state

And the order is associated with the consumer

And the order is associated with the restaurant

• AcceptOrder story

Given an order that is in the PENDING_ACCEPTANCE state

and a courier that is available to deliver the order

When a restaurant accepts an order with a promise to prepare by a particulartime

Then the state of the order is changed to ACCEPTED

And the order's promiseByTime is updated to the promised time

And the courier is assigned to deliver the order

• Class diagram

The responsibilities of each class are as follows:

• Consumer —A consumer who places orders.
• Order —An order placed by a consumer. It describes the order and tracks its status.
• OrderLineItem —A line item of an Order .
• DeliveryInfo —The time and place to deliver an order.
• Restaurant —A restaurant that prepares orders for delivery to consumers.
• MenuItem —An item on the restaurant’s menu.
• Courier —A courier who deliver orders to consumers. It tracks the availability of the courier and their current location.
• Address —The address of a Consumer or a Restaurant .
• Location —The latitude and longitude of a Courier .

Define system operations

There are two types of system operations:

• Commands: Create, update, delete data
• Queries: System operations that read(query) data

A command has a specification that defines parameters, return value and behavior in terms of the domain model classes

• pre-conditions that must be true when the operation is invoked
• post-conditions that are true after the operation is invoked.

Flows when a consumer places an order:

• User enter delivery address and time
• System displays available restaurants
• User selects restaurant
• System displays menu
• User selects item and checks out
• System creates order

This user scenario suggests the following queries:

• findAvailableRestaurants(deliveryAddress, deliveryTime)
• findRestaurantMenu(id)

Define services

By applying business capability

A business capability is something that a business does in order to generate value

Business capability define what an organization does.

The business capabilities for FTGO include the following:

• Supplier management:

  • Courier management: Managing courier information
  • Restaurant information management: Manage restaurant menus and other information, including location and open hours

• Consumer management: Manging information about consumers

• Order taking and fullfillment:

  • Order management: Enabling consumers to create and manage orders
  • Restaurant order management: Managing the preparation of orders at a restaurant
  • Logistics
  • Courier availability management: Managing the real-time availability of couriers to delivery orders
  • Delivery management: Delivering orders to consumers

• Accounting:

  • Consumer accounting: Managing billing of consumers
  • Restaurant accounting: Managing payments to restaurants
  • Courier accounting: Courier accounting

From business capability to services

Defining services by applying the Decompose by sub-domain pattern

Decomposition guidelines

• SINGLE RESPONSIBILITY PRINCIPLE: Each responsibility that a class has is a potential reason for that class to change.
• COMMON CLOSURE PRINCIPLE: If two classes change in lockstep because of the same underlying reason, then they belong in the same package. The goal is that when that business rule changes, developers only need to change code in a small number of packages (ideally only one)

Obstacles to decomposing an application into services

• Network latency: a particular decomposition into services results in a large number of round-trips between two services. Sometimes, you can reduce the latency to an acceptable amount by implementing a batch API for fetching multiple objects in a single round trip

• Reduced availability due to synchronous communication:

• Maintaining data consistency across services: Some system operations need to update data in multiple services. For example, when a restaurant accepts an order, updates must occur in both the Kitchen Service and the Delivery Service . The Kitchen Service changes the status of the Ticket . The Delivery Service sched- ules delivery of the order. Both of these updates must be done atomically.

  - Traditional solution: Two-phase, commit-based, distributed trans-

  action management mechanism

  - Saga: A sequence of local transactions that are coordinated using messaging

• Obtaining a consistent view of the data: In a microservice architecture, even though each service’s database is consis- tent, you can’t obtain a globally consistent view of the data

Defining service API

Asigning system operation to services

The first step is to decide which service is the initial entry point for a request

Determining the APIs Required to support collaboration between services

For example, in order to implement the createOrder() operation, the Order Service must invoke the following services in order to verify its preconditions and make the post-conditions become true:

• Consumer Service —Verify that the consumer can place an order and obtain their payment information.
• Restaurant Service —Validate the order line items, verify that the delivery address/time is within the restaurant’s service area, verify order minimum is met, and obtain prices for the order line items.
• Kitchen Service —Create the Ticket .
• Accounting Service —Authorize the consumer’s credit card.

In order to implement the acceptOrder() system operation, the Kitchen Service must invoke the Delivery Service to schedule a courier to deliver the order