Microservices Decomposition Patterns

Editor's Notes

• #6  Conway's Law, which states that a system mimics its communication structure
• #7 Domain Driven Design(DDD) is an approach to building software that tries to tackle the complexity of the business by focusing on the core domain, building an evolvable model of the domain, and involving domain experts in the evolution of the model to develop and ensure a consistent understanding and language. You can think of a domain as a problem space. For example, allowing people to order food online from their local takeaway, and giving restaurants an online presence and the ability to process orders with no upfront investment in infrastructure is the problem space of JUST EAT. I try to explain these concepts with my understanding. In DDD, everything should be communicated under ubiquitous language so the technical team and business team can use the same terms and have same views on the problems Domain in DDD represent real problem in business. Such as: E commerce is a domain, Payroll system is a domain Domain is divided into many sub domains, so each sub domains focus smaller problems. Such as: E commerce has many sub domains such as: Shopping Cart, Billing, Product Catalog, Customer Information... Each sub domain should have explicit responsibilities so it has a boundary to limit their functionalities, the boundary will help sub domain focus to do only 1 thing and do well. This boundary is considered as bounded context of the sub domain. The bounded context will define: How many domain models needed for the sub domain? Which properties needed in the each model? Which functionalities needed in sub domain? Ex: Shopping Cart sub domain needs models: Cart, Product, Customer Info... and contains functions to perform CRUD on the cart. Notes: The Product and Customer model in the Shopping Cart sub domain maybe not the same with the models in Product Catalogs and Customer Profiles sub domain, they just contain necessary properties to display on Shopping Cart. A sub-domain delimits a domain and exists within the problem space. A bounded context delimits the domain model and exists within the solution space. The ideal is full alignment between a sub-domain and a bounded context, however in practice a degree of flexibility must be accepted in this regard.  That’s why the domain is called a Problem space A bounded context must not require synchronous communication with other contexts in order to execute its business logic. And I don't just mean synchronous in technology. If there is an asynchronous messaging system between contexts, but the context has to wait for an answer, that is still synchronous. A bounded context should still work if all other contexts are removed (services are stopped). 6 a) With BCs containing two or more subdomains there's a possibility of concepts overlapping and even worse, the same concept ( used by several of these subdomains ) may be interpreted/understood differently by each subdomain. sub-domain is problem space and bounded context is solution space, but in general case they should be 1:1. For legacy code it is ok to have more than one bounded context per sub-domain, but NOT the other way arround - one bounded context should not cover more than one sub-domain A subdomain is a problem of a larger domain and a bounded context is the solution space where that problem will get solved in practice. You should strive to have a 1 to 1 alignment between subdomains and bounded contexts, just like you would ideally have a 1 to 1 alignment between questions and answers Imagine a software that is being developed to support a dentist. A dentist has two problems: fixing patients’ teeth and making appointments for the patients. Fixing teeth is the core domain and making appointments is a supporting subdomain. In the core domain the medical staff cares about a patient’s dental history, can they handle general anesthesia or not, what their current problem is, etc. In the subdomain the staff (not necessarily medical staff) cares about a patient’s contact information, a date and a time that best suits both the doctor and the patient, the type of dental work needed, etc. Both domains need a model of a patient, but that model will depend on the bounded context we put in place to ensure the correct information and features are available when solving the problems of each domain. The domain represents the problem to solve; the domain model is the model that implements the solution to the problem. Likewise, a subdomain is a segment of the domain, and a bounded context is a segment of the solution. words often have different meanings in different contexts. To overcome this hurdle, DDD requires each language to have a strict applicability context. This context is called a Bounded Context. It defines a boundary, inside of which a Ubiquitous Language can be used freely. Outside of it, the language’s terms may have different meanings. “If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions” - Albert Einstein When choosing between business subdomains and entities, he claims that the best level of decomposition depends on the system you are building together with its use cases. He emphasizes that microservices is not really about the inside of a service, but rather about the interaction and coupling between services. The threshold upon which a system can be decomposed into microservices is defined by the use cases of the system that the microservice is part of. In contrast to SOA, micro-services gives an answer to the question of how big a service should be and how they should communicate with each other. In micro-services architecture, services should be small and the protocols should be lightweight. A bounded context is a projection in the solution space to define boundaries in the system implementing the domain. Bounded contexts are important because they allow to define an ubiquitous language, valid within their boundaries. A product in a billing bounded context has not the same meaning than in a shipping bounded context. When it is badly done, we obtain a big ball of mud, e.g. a huge system without boundaries where an update in the billing part may cause side effect in the shipping part. We are in the solution space because it is an actual description of how we implement the domain. A bounded context does not necessarily matches exactly one sub domain. But having too many bounded contexts overlapping between different sub-domains is definitely a design smell. And of course, we still cannot decide, because we still lack the (business) context. In some business context, a micro service might fit a bounded context. In some other, several micro services will be in one bounded context. The only thing we can suppose is that a micro service overlapping different bounded contexts has something wrong. “At Amazon, what sub-domains?” •Catalog •Recommandation •Shipping •Billing •Shopping cart •Customer review •Book Search •Search Inside!
• #8 the organizational relationships and dependencies - are visualized in DDD in a so-called Context Map In the example, the relationship between the optimal acquisition and the prizing context is a BC pattern partnership. This means that when both teams change something that could influence the other context, both teams will vote. In principle, they plan their approach together and develop in parallel. A less friendly relationship exists between Inventory and ERP. This often occurring case in practice, that old or external systems must be connected, requires special care. Since these systems can not usually be changed by us, we must introduce mechanisms that prevent a "corruption" of our context. If something changes there. And conversely, we are often forced to adopt certain specifications of these systems. Ideally, we build a so-called anti-corruption layer (ACL) before our context. He is a kind of interpreter between the different worlds and makes sure that our domain model remains clean and protected against these outside influences  Always with the focus on small steps and fast feedback ● Steps: ○ List Problem Space and Solution Space ○ Draw Problem Space on the Domain map and separate Core, Supporting and Generic ○ Fill in the Bounded Context ○ Discussion and sharing List two spaces first Problem Space ● Helping guests to buy things they want to buy (product recommendation) ● Inventory management ● Purchase of goods ● Privilege check ● Human resource management ● Corporate financial management Solution Space ● Optimal acquisition Context ● Inventory Context ● Map Context ● Purchase Context ● ERP Context Subdomains ● Core subdomain core sub-area ○ Reasons/problems that make the whole system worthy of being developed ○ Cannot be replaced by ready-made or outsourced ○ If core subdomain is not the most important of the entire architecture, it means that your architecture is not designed well. ○ It takes a lot of effort to develop ● Supporting subdomain supports sub-areas ○ Non-core, but supports the core needs ○ Focus on one aspect of the business ○ Available off-the-shelf tools or outsourcing as appropriate ● Generic domain universal subdomain ○ Non-core, but used for the entire system (similar to infrastructure) ○ may also be used by supporting subdomain ○ Outsourced, ready-to-use kits ○ ex: identity authentication system, operating system Different (Sub)Domains Different language Linguistic Contexts •Sales -> Customer •Shipping -> Recipient •Billing -> Account •Marketing -> Segment, Audience Core Domains. The core parts of the system represent the fundamental competitive advantage that your company can gain through the delivery of this software.— What are the parts of the product that will make it a success?— Why are these parts of the system important?— And why can’t they be bought off the shelf?— In other words, what makes your system worth building? Generic Domains. A generic domain is a subdomain that many large business systems have. An example of a generic domain is an e-mail sending service.Because these subdomains aren’t core and won’t give you a competitive edge, it doesn’t make sense to spend a lot of effort or investment in building them. Instead, look to buy in software for generic domains. Supporting Domains. These are subdomains that, although not defining what your system does, help to support your core domains.It’s important to note that you may not always need to implement a technical solution to a supporting domain.
• #9 Recipient Shipping Account Billing Segment, Audience Marketing
• #10 Different (Sub)Domains Different Evolution and Different Feature / Change Requests Complex Business Logic Failure on Customer will failure on Shipping and Billing Not fullfil Microservice goals
• #11 Achieve Autonomous Team Avoid distributed monolith application Avoid cascading failure Simplify the complexity of the business logic Achieve Business and IT alignment But Create duplicate data
• #12 DRY Coupling Centralize Isolation Redundancy Decentralize Bounded Contexts: We decide to reduce coupling at the cost of some duplication
• #18 Entity—An object that has a persistent identity. Two entities whose attributes have the same values are still different objects. In a Java EE application, classes that are persisted using JPA @Entity are usually DDD entities.  Value object—An object that is a collection of values. Two value objects whose attributes have the same values can be used interchangeably. An example of a value object is a Money class, which consists of a currency and an amount.  Factory—An object or method that implements object creation logic that’s too complex to be done directly by a constructor. It can also hide the concrete classes that are instantiated. A factory might be implemented as a static method of a class.  Repository—An object that provides access to persistent entities and encapsulates the mechanism for accessing the database.  Service—An object that implements business logic that doesn’t belong in an entity or a value object.