윈도우 앱개발을 향하여

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의 강의를 들으실 수도 있습니다.

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

The Screaming Architecture

"The architecture should scream the intent of the system!" - Uncle Bob

Organizing architecture around the use cases of the system. Use cases are representation of a user's interaction with the system.

We can organize our application's folder structure and namespaces according to the components that are used to build the software, components like models, views, and controllers or we can organize our folder structure and namespaces according to the use cases of the system, concepts that pertain to user's interactions with objects in the system like customers, products and vendors. 

Why Use Functional Organization?

Pros

Spatial locality : items that are used together live together

Easy to navigate the folder structure

Avoid vendor lock-in

Cons

Lose framework conventions : so we typically have to tell framework where things are located

Lose automatic scaffolding

Categorical is easier at first

출처

이 모든 내용은 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의 강의를 들으실 수도 있습니다.

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

Commands and Queries

CQRS Architectures

Pros and Cons

Command-Query Separation

Command

Does something

Should modify state

Should not return a value

Query

Answers a question

Should not modify state

Should return a value

Command-Query separation is a good idea, but not always possible.

e.g. Pop a stack (Remove item - command, Return top item - query)

e.g. Create a new record (Create record - command, Return new ID - query)

So in general we should strive to maintain command query separation where possible.

Command Query Responsibility Separation(CQRS) Architecture

Expand command query separation to the architectural level.

Dividing the architecture into a command stack, and a query stack, starting at the application layer. Because queries should be optimized for reading data, whereas commands should be optimized for writing data. 

Command execute behaviors in the domain model, mutate state, raise event, and write to the database.

Queries use whatever means is most suitable to retrieve data from the database, project it into a format for presentation, and display it to the user.

This change increases both the performance of the commands and queries, but equally important, it increases the clarity of the respective code. CQRS is domain-centric architecture done in a smart way

Three types of CQRS Architecture

Single-database CQRS : Commands use domain, Queries use database (Simplest)

Two-database CQRS : Read and writhe databases, Commands use write DB, Queries use read DB, Eventual consistency between databases, Orders of magnitude faster

Event Sourcing CQRS : do not store the current state of our entities in a normalized data store. Store events (store historical record of all events in a persistence medium called an event store. Replay events. Modify entity. Store new event. Update read database.

Complete audit trail, Point-in-time reconstruction, Replay events(good for debugging and testing), Multiple read database, Rebuild production database.

Why Use CQRS?

Pros

More efficient design

Optimized performance

Event sourcing benefits

Cons

Inconsistent across stacks

More complex

Event sourcing 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의 강의를 들으실 수도 있습니다.