Microservice (part4)

you should have read part3 before going on this section.

Defining services by business capability

The set of capabilities for a given business depends on the kind of business. For example, the capabilities of an insurance company typically include Underwriting, Claims management, Billing, Compliance, and so on. The capabilities of an online store include Order Management, Inventory
management, Shipping, and so on

we should capture what an organization’s business is rather than How they do them. it wasn’t that long ago that you deposited checks at your bank by handing them to a teller. It then became possible to deposit checks using an ATM. Today you can conveniently deposit most checks using your smartphone. As you can see, the Deposit check business capability has remained stable. Each business capability can be thought of as a service.

A capability can often be decomposed into sub-capabilities. For example, the Claim management capability has several sub-capabilities, including Claim information management, Claim review, and Claim payment management

for the FITGO application, the top-level capabilities and sub-capabilities include Supplier management, Consumer Management, Order taking and fulfillment, and Accounting. after determining capabilities we can map those capabilities to services like below.

Defining services by domain-driven design

in this approach services will decompose by object-oriented domain model. each domain defines the vocabulary used by the team ( a Ubiquitous Language)

in DDD you have to know two concept that are incredibly useful when applying the microservice. subdomains and bounded context.

in traditional business modeling we had a single definition of each business entity, such as customer, order, and so on. The problem with this kind of modeling is that getting different parts of an organization to agree on a single model is a monumental task. in some point, domain model can be confusing because different parts of the organization might use the same term for different concepts or different terms for the same concept.DDD defines a separate domain model for each subdomain. A subdomain is a part
of the domain. Subdomains are identified using the same approach as identifying business capabilities.

The examples of subdomains in FTGO include Order taking, Order management, Kitchen management, Delivery, and Financials.

DDD calls the scope of a domain model a bounded context. When using the microservice architecture, each bounded context is a service or possibly a set of services. We can create a microservice architecture by applying DDD and defining a service for each subdomain.

note that each domain model being owned and developed by a single team.

Decompose by subdomain and Decompose by business capability are the two main patterns for defining an application’s microservice architecture