(Clean Architecture) Microservices

Copyright

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 여섯번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 저작자님께 게시허가도 받았습니다.

Content

1. Clean Architecture

2. Domain-centric Architecture

3. Application Layer 

4. Commands and Queries (CQRS)

5. Functional Organization

6. Microservices

7. Testable Architecture

8. Evolving the Architecture

Outline

Bounded Context

Microservices

Pros and Cons

Components

Components are how we would typically subdivide the layers of our architecture once it has grown beyond a manageable size. We typically implement components as separate projects within our overall solution, then when we build these projects we create output files like DLLs in C#, assemblies in .NET, jar files in Java, and gem files in Ruby. This allows us to work on the components individually, integrate them as necessary, and deploy them independently.

Our users interact with the application typically through a composite user interface, which calls the appropriate component stack, and presents the user interface as a unified view of the system. In addition, all of the data for each component stack are typically stored in a single database.

Single Domain Model

Creating a single unified domain model by merging all the functions that pointed to the same types of physical objects and mental concepts as a single entity can derive a problems as we try to model larger and larger domains. It becomes progressively harder to create a single unified domain model. The problem is that models are only applicable within a specific context(Sales and Support). When we try to force a model to work within multiple contexts, We have extra unused properties, methods, and validation rules that are applicable in one context, but not in other contexts.

A bounded context is the recognition of a specific contextual scope within which a specific model is valid. We constrain our domain model by each bounded context, and subdivide our models appropriately. Then we communicate state transitions of our cross boundary models from one domain to the other. We do this through clearly defined interfaces using either coordinated transactions or an eventual consistency model. This leads us to microservices.

Microservices

Microservice architectures subdivide monolithic applications; that is, the divide a single, large application into smaller subsystems. These microservices communicate with one another using clearly defined interfaces, typically over lightweight web protocols(like JSON over HTTP via res APIs).

Microservices can also subdivide large teams into smaller development teams; that is, one team for each microservice or set of microservices.

These services are also very independent of one another. Each one can have its own persistence medium, programming language, architecture, and OS. In addition, you can independently deploy each microservice and independently scale them as needed.

Microservices are similar in concept to SOA(Service oriented architecture).

Then...

How big should each microservice be?

Where should I draw the boundaries of each microservice?

Bounded context

Ideally, in most cases we want each domain, each microservice, each database, and each corresponding deevelopment team to line up to maximize Cohesion/coupling, Single domain of knowledge, Consistent data model, Independence. However there's still a lot of debate in the industry as to how small microservices should be and where to divide. even if each domain contains database, Information is still exchanged between bounded context via each bounded context set of microservices. There are definite pros and cons to both of these equally reasonable ways to organize your micorservices; however, it's up to each of you to decide what makes the most sense for your project and architect your microservices accordingly.

Why Use Microservices?

Pros

Flatter cost curve

High cohesion and low coupling

Independence : can use whatever technology, design pattern that most appropriate for each specific microservice

Cons

Higher up-front cost

Conway's' Law

Distributed system costs

출처

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 여섯번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 제가 정리한 것보다 더 많은 내용과 Demo를 포함하고 있으며 최종 Summary는 생략하겠습니다. Microsoft 지원을 통해 한달간 무료로 Pluralsight의 강의를 들으실 수도 있습니다.