윈도우 앱개발을 향하여

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

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

Application Layer

Dependency Inversion Principle

Pros and Cons

What are Layers?

Layers are boundaries or vertical partitions of an application designed to represent different levels of abstraction, maintain the single responsibility principle, isolate developer roles and skills, help support multiple implementations, and assist with varying rates of change.

Essentially, layers are the way that we slice an application into manageable units of complexity.

Classic Three-layer Architecture

User interface Layer : provides the user with an interface into the application 

Business Logic Layer : contains the business logic of the application

Data Access Layer : contains the logic to read and write to the database.

Modern Four-layer Architecture

Presentation Layer : provides the user with an interface into the application

Application Layer : embeds the use cases of the application as executable code and abstractions

Domain Layer : contains only the domain logic of the application

Infrastructure Layer : oftentimes it makes sense to divide this layer into one or more projects

e.g. common variation is to create a separate project for persistence, and a separate project for the remaining infrastructure. In diagram on the left create Persistence project to provides the application with an interface to the database or other persistent storage.

Cross-cutting Concerns Layer : aspects of the application that cross all the layers of the system

Application Layer

Implements use cases as executable code

e.g. a customer searches for a project, adds it to their cart, and pays with a credit card.

High-level representations of application logic.

e.g. a query that searches for our project for our customer or a command that adds a product to their shopping cart.

The application layer knows about the domain layer, that is, it has a dependency on the domain, but it does not know about the presentation, persistence or infrastructure layers(no dependencies on the outer layers of the application).

The application layer, however, does contain interfaces for its dependencies that these respective outer layers then implement. Then we use an IoC framework(inversion of Control framework) and dependency injection to wire up all the interfaces and their implementations at run time.

We can follow the flow of control through the application from the users at the top of the diagram down to the database and OS at the bottom of the diagram. In addition, we can follow the dependency arrows, which flow both upwards and downwards towards the domain.

Unlike classic three layer architecture, Persistence and Infrastructure layer depends on application layer. These inverted dependencies comes from the dependency inversion principle. It states that abstraction should not depend on details, rather, details should depend on abstractions. So in the persistence and infrastructure layers we implement the inversion of control pattern. That is, our dependencies oppose the flow of control in our application. This provides several benefits, such as providing independent deployability. That is, we can replace an implementation in production without affecting the abstraction that is depends upon. It also makes architecture more flexible and maintainable as well. For example, we can swap out our persistence medium and infrastructure dependencies without having negative side effects ripple throughout both the application and domain layers. This is highly useful for agile applications where we often defer implementation decisions as late as possible when we have a much better understanding of the specific needs of our application and its implementations. This it a strategy referred to in Agile software development as the last responsible moment.

Sometimes we need to add an additional dependency from the persistence project directly to the domain project when using an Object Relational Mapper(ORM). This is necessary for the ORM to map domain entities to tables in the database since the persistence layer needs to know about the entities contained int the domain layer. Using an ORM is optional when creating clean architecture, but it can save a tremendous amount of development time if used correctly.

Demo

In the Presentation project : SalesController that has a dependency on the ICreateSalesCommand interface in the application project.

In the Application project : CreateSaleCommand class implements ICreateSalesCommand interface and contains the high level application logic that fulfills the use case for creating a new sale. The class has a dependency on the IDatabaseService interface and IInventoryService interface both of which contained in the application project as well.

In the Persistence project :  DatabaseService class implements the IDatabaseService interface

In the Infrastructure project : InventoryService class implements the IInventoryService interface.

All of the dependencies point towards the application and thus transitively towards the domain. All of the details, that is implementations, depend upon abstractions, which are interfaces, and we utilize inversion of control for both the persistence and Infrastructure projects dependency on the application project.

Cross-cutting concerns are a bit different, as there are typically multiple projects that all have dependencies upon them. So Cross-cutting concerns project store both the interfaces and the implementations(IDateService interface and DateService class). Then multiple classes(CreateSaleCommand, SalesController, DatabaseService, Sale and InventoryService uses IDateService)

Why Use an Application Layer

Pros

Focus on use cases

Easy to understand

Follows DIP(Dependency Inversion Principle

Cons

Additional layer cost : Layers in software architecture are expensive to create and maintain

Requires extra thoughts : to separate application layer from domain layer

IoC is counter-intuitive

출처

이 모든 내용은 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

Domain-centric Architecture

Types of Domain-centric Architectures

Pros and Cons

Database-centric vs Domain-centric Architecture

On classic three-layer Database-centric Architecture, Data Access is essential(center of architecture). then Business Logic, then UI

On Domain-centric Architecture let Domain in the center and making the database just an implementation detail outside of the architecture.

"설계의 최우선 관심사는 집의 사용가능성(domain)을 보장하는 것이지, 그 집이 벽돌(data access)로 지어질것을 보장하는 것이 아니다."

=> 집의 공간과 사용성은 필수적인 고려대상이나 건물의 재질과 외관장식은 디테일에 불과하다.

Types of Domain-centric Architectures

1. Hexagonal Architecture, Alistair Cockburn

2. Onion Architecture, Jeffrey Palermo

3. Clean Architecture, Uncle Bob

Put the domain model at the center, wrap it in an application layer, which embeds the use cases, adapts the application to the implementation details, and all dependencies should point inwards towards the domain

Pros and Cons

Pros

Focus on domain(which is essential to the inhabitants of the architecture)

Less coupling between the domain logic and the implementation details

Allows for DDD(Domain Driven Design, set of strategies for handling business domains with a high degree of complexity)

Cons

Requires more thought

Initial higher cost

출처

이 모든 내용은 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

Levels of Architectural Abstraction

What is Bad Architecture?

What is Good Architecture?

What is Clean Architecture?

Levels of Architectural Abstraction

System : the most abstract representation of software

Sub-system : System can be represented as a set of one or more subsystems

Layers : Sub-systems are typically divided into one or more layers

Components : Layers are often subdivided into one or more components

Classes : Components contain classes

Data and Methods : Classes contains data and methods

What is Bad Architecture?

Complex

Incoherent : the parts don't seem like they fit together

Rigid : hard to change or evolve the architecture

Brittle : touching a part of the code over here might break another part of the code somewhere else

Untestable

==> Unmaintainable

What is Good Architecture?

Simple

Understandable

Flexible

Emergent

Testable

==> Maintainable

What is Clean Architecture?

Architecture that is designed for the inhabitants(User, developers who building or maintaining the system) of the architecture. Not for the architect or the machine. Clean architecture is a philosophy of architectural essentialism. It's about focusing on what is truly essential to the software's architecture versus what is just an implementation detail.

Focus on the essential

Build only what is necessary

Optimize for maintainability

Context is king

All decisions are a tradeoff

Align with business goals

Use your best judgement

출처

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