Microservices Decomposition Patterns
•Transferir como PPTX, PDF•
4 gostaram•2,094 visualizações
Microservices Pattern Language Microservices Software Architecture Governance, Best Practices and Design Pattern Decomposition Patterns Decompose by Business Capability Decompose by Subdomain
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Microservices Decomposition Patterns
Semelhante a Microservices Decomposition Patterns (20)
Mais de Firmansyah, SCJP, OCEWCD, OCEWSD, TOGAF, OCMJEA, CEH
Mais de Firmansyah, SCJP, OCEWCD, OCEWSD, TOGAF, OCMJEA, CEH (11)
Último
Último (20)
Microservices Decomposition Patterns
- 1. Microservices Pattern Language Microservices Software Architecture Governance, Best Practices and Design Pattern 5 October 2019 Firmansyah
- 2. 5 October 2019 2 Decomposition Patterns • Decompose by Business Capability • Decompose by Subdomain 03
- 3. Microservice Decomposition Objective 1. Achieve autonomous team and autonomous services 2. Avoid distributed monolith application 3. Avoid cascading failure 4. Simplify the complexity of the business logic 5. Achieve Business and IT alignment 6. Estimate sizing and licenses 5 October 20193
- 4. Microservice Decomposition Strategy The process to define Microservice decomposition. 5 October 20194 Stage 1 (Design) • Decompose by Business Capability or • Decompose by Subdomain Stage 2 (Development) • Apply Single Responsibility Principle • Apply Common Closure Principle Stage 3 (Testing) • Decompose by Resource Isolation for HA
- 5. Decompose by Business Capability Pattern The Steps of Decomposition by Business Capability Patterns 5 October 20195 The Steps: 1. Identified Business Capabilities: An organization’s business capabilities are identified by analyzing the organization’s purpose, structure, service, and business processes that a business does in order to generate value.. 2. Define Service Once you’ve identified the business capabilities, you then define a service for each capability or group of related capabilities. The decision of which level of the capability hierarchy to map to services is somewhat subjective. Conway's Law: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure
- 6. Decompose by Subdomain Pattern 5 October 20196 Analyze Domain Identify Subdomain Define Bounded Contexts Design Microservices Domain is a particular area of knowledge or activity or problem to be addressed with a software solution. Example domains are Online Food, Online banking, Airline booking, E- commerce, Payroll System, etc. A domain can be decomposed into sub- domains which typically focus smaller problems. In Online Food domain, the example of sub-domains are Order taking, Delivery, Kitchen, Accounting, etc. E-commerce has many sub domains such as: Shopping Cart, Billing, Product Catalog, Customer Information, etc Bounded Context is an autonomous solution to a single sub-domain, which implements boundary of a certain business capability. The bounded context will define domain models which properties needed in the each model. Ex: The Product and Customer model in the Shopping Cart sub domain maybe not the same with the models in Product Catalogs and Customer Information sub domain, they just contain necessary properties to display on Shopping Cart. Each bounded context correlates to one or several microservice, depend on business context. A microservice can’t overlapping different bounded contexts Domain-driven design help to design Microservices that loosely coupled and cohesive. DDD, which is described in the book Domain-Driven Design by Eric Evans. Problem Space Solution Space
- 7. Type of Subdomain Pattern and Bounded Context Core Subdomains = • It differentiates a business from competitors. • It makes most of the profit for the company. • The most investments in terms of development time, care and attention 5 October 20197 Supporting Subdomains = • Supports the core needs. Generic Subdomains = • It used for the entire system • It won’t give a competitive edge • It doesn’t make sense to spend a lot of effort or investment in building them The Bounded Context: • It will define Domain Model Pattern and Aggregate Pattern so then it will define Microservice • It should not cover more than one sub- domain except for Generic subdomain. • A subdomain can be decomposed into more than one bounded context. • It define an ubiquitous language, valid within their boundaries.
- 8. Ubiquitous Language Different Bounded Context - Different language 5 October 20198 Specific Language Bounded Context Customer Sales Recipient Shipping Account Billing Segment, Audience Marketing
- 9. If We Not Using Bounded Context Every Feature / Change Requests in One Domain Model 5 October 20199 Customer addressLine zipcode city … Customer addressLine zipcode city has2AddressesFlag addressLine2 zipcode2 city2 Customer have a different billing address! If (! has2AddressesFlag) billing address line = … billing zip code = billing city = else billing address line = … billing zip code = billing city =
- 10. If We Using Bounded Context Split by business domains or business capabilities 5 October 201910 Customer date amount … Account addressLine zipcode City … Recipient addressLine zipcode City … • Achieve Autonomous Team • Avoid distributed monolith application • Avoid cascading failure • Simplify the complexity of the business logic • Achieve Business and IT alignment But • Create partial duplication of data • How to correlate or integrate the data? • How to create data consistency and data integrity? • How to create effective and efficient query?
- 11. Bounded Context Implication 5 October 201911 Independence Duplication Decentralize DRY Coupling Centralize Bounded Contexts: We decide to reduce coupling at the cost of some duplication
- 12. Bounded Context Implication Evolve differently in the long term 5 October 201912 Account addressLine zipcode City Recipient addressLine zipcode City Account addressLine zipcode City postbox Recipient addressLine zipcode City doorCode
- 13. Correlation and Integrity Data Bounded Context will define Domain Model Pattern, Aggregate Pattern and Saga Pattern so then it will define best in class of Microservice Architecture. 5 October 201913 The Delivery Info and Payment Info model in the Order Service sub domain maybe not the same with the models in Customer Service sub domain, they just contain necessary properties to display on Order Service Saga Pattern ACID Basically Available Soft state Eventually consistent Atomicity Consistency Isolation Durability Root Entity Root Entity Root Entity Value Object Value Object Value Object Value Object Value Object
- 14. Database Queries Patterns Overview There are 3 type database query patterns in Microservice Architecture 5 October 201914 No Database Queries Patterns Purpose 1. API Service Query on single service 2. API Composition Query on multiple services with simple primary key-based equi-join query 3. Command Query Responsibility Segregation (CQRS) a) Query on single service for separation of concerns (SoC) and provide the fit for purpose database b) Query on data which belong to multiple services and support complex query (Join-Filter-Sort- Pagination) and provide the fit for purpose database
- 15. Decompose by Resource Isolation for HA Decompose to avoid competition on shared resources 5 October 201915
- 16. Decompose by Resource Isolation for HA Decompose to avoid competition on shared resources 5 October 201916
- 17. Decomposition Patterns Summary Decomposition Guiding Principle 5 October 201917 No Principle 1. The architecture must be stable since the business capabilities and the subdomains are relatively stable. 2. Services must be cohesive (Single Responsibility Principle). A service should implement a small set of strongly related functions (Keep services that communicate less in separate components). 3. Services must conform to the Common Closure Principle - things that change together and communicate intensely should be packaged together - to ensure that each change affect only one service. 4. Services must be loosely coupled - each service as an API that encapsulates its implementation. The implementation can be changed without affecting clients 5. A service should be testable 6. Each service be small enough to be developed by a “two pizza” team, i.e. a team of 6-10 people 7. Each team that owns one or more services must be autonomous. A team must be able to develop, deploy and scale their services with minimal collaboration with other teams. 8. The emphasis should not be on the size but on above principles
Notas do Editor
- Conway's Law, which states that a system mimics its communication structure
- 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!
- 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.
- Recipient Shipping Account Billing Segment, Audience Marketing
- 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
- 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
- DRY Coupling Centralize Isolation Redundancy Decentralize Bounded Contexts: We decide to reduce coupling at the cost of some duplication
- 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.