윈도우 앱개발을 향하여

Copyright

이 모든 내용은 Pluralsight에 Dino Esposito가 올린 'Modern Software Architecture: Domain Models, CQRS, and Event Sourcing'라는 강의의 두번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/modern-software-architecture-domain-models-cqrs-event-sourcing/table-of-contents). 강의 원작자분께 게시허가도 받았습니다.

Content

Discovering the Domain Architecture through DDD

The DDD Layered Architecture

The "Domain Model" Supporting Architecture

The CQRS Supporting Architecture

Event Sourcing

Designing Software Driven by the Domain

Outline

Typical DDD flowchart

Common Summary of DDD

Ubiquitous Language

Defining the Ubiquitous Language

Bounded Contexts

Discovering Bounded context

Context Mapping

Event storming

Typical DDD flowchart

1. Crunch knowledge about the domain

2. Recognize subdomains

3. Design a rich domain model

For each recognized subdomain, design a rich object model that, regardless of concerns like persistence and databases, describe how involved entities behave and our action by user

4. Code by telling objects in the domain model what to do

Common Summary of DDD

DDD is all about building an object model for the business domain called a domain model, and consuming the model in a context of a multilayered architecture(4 layers, business logic split and renamed Application layer and Domain layer).

However the best part of DDD is in the tools it provides to understand and make sense of the domain.

DDD has two distinct parts. You always need one but can happily ignore the other.

DDD has an analytical part that essentially sets an approach to express the top level architecture ideal for the business domain you are considering. The top level architecture is expressed in the terms of constituent elements subdomains that are referred to as bounded context in accordance with the specific DDD jargon. Valuable to everybody and every project.

DDD has a strategic part that instead relates to the definition of a supporting architecture for each of the identified bounded contexts. One of many possible supporting architectures

Ubiquitous Language

Vocabulary of domain-specific terms

Nouns, verbs, adjectives, idiomatic expressions and even adverbs

Shared by all parties involved in the project

Primary goal of avoiding misunderstandings and bad assumptions

Used in all forms of spoken and written communication

Universal language of the business as done in the organization

The ubiquitous language is the language of the domain model being built, but it's very close to the natural language of the business domain. It's not artificially created, but it just comes out of interviews and brainstorming sessions. Unambiguous and fluent.

(People use different languages, Common terminology, Help making sense of user requirements)

Structure

List of terms saved to documents

Glossary of terms fully explained

Mad available to everyone

Part of the project documentation

Continuously updated

Responsibility of the development team

If ubiquitous changes, the model should be changed and subsequently code also changed

Defining the Ubiquitous Language

"Discovering the ubiquitous language

leads you to understand the business domain

in order to design a model"

PS: Any model that works. Not necessarily an object-oriented model. It can be, for example, a functional model where no classes are used at all, but functions and stored procedures to deal with data.

Start from User Requirements!

Discovery of the terms that make up the ubiquitous language starts from user requirements. Get Noun and Verb from it

Ubiquitous language == Words and verbs that truly reflect the semantics of the business domain

At Work Defining the Ubiquitous Language

Different concepts named differently.

Matching concepts named equally.

to communicate each other without misunderstanding between co-workers

The ubiquitous language is neither the role language of the business nor the language of development

Naming convention is critical : Classes, Members, Namespaces

Bounded Contexts

Delimited space where an element has a well-defined meaning

Any elements of the ubiquitous language

Beyond the boundaries of the context, the language changes

Each bounded context has its own ubiquitous language

Business domain split in a web of interconnected contexts

Each context has its own architecture and implementation

Bounded contexts in DDD serve three main purposes

Remove ambiguity and duplication

Simplify design of software modules

Integration of external components

Discovering Bounded context

A bounded context is an area of the domain model that has its own ubiquitous language, its own independent implementation based on a supporting architecture, such as CQRS, and a public documented interface to interact with other bounded contexts.

Context Mapping

Context map is the diagram that provides a comprehensive view of the system being designed

Relationship between bounded contexts

Direction of relationship

Upstream context influence downstream context

Relationships

Conformist

Downstream context depends on upstream context, No negotiation possible

Customer/Supplier

Customer context depends on supplier context

Chance to raise concerns and have them addressed in some way

Partner

Mutual dependency between the two contexts, which depend on each other for the actual delivery of the code

Shared Kernel

Shared model that can't be changed without consulting teams in charge of contexts that depend on it

Anti-corruption Layer

Additional layer giving the downstream context a fixed interface no matter what happens in the upstream context

Event storming

Prerequisite : developers and domain experts, Meeting room with Board, Sticky notes, marker etc

An event storming session consists in talking about observable events in the business domain and listing them to the wall or whiteboard.

A sticky note of a given color is appointed on the modeling surface when an event is identified.

출처

이 모든 내용은 Pluralsight에 Dino Esposito가 올린 'Modern Software Architecture: Domain Models, CQRS, and Event Sourcing'라는 강의의 두번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/modern-software-architecture-domain-models-cqrs-event-sourcing/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

Last Responsible Moment

Make informed decisions

Deciding too early is a risk

Deciding too late is a risk

Defer decisions until LRM

Evolving the Architecture

Eliminate risk early

Technology may change

Markets may change

Preferences may change

Why Use Evolutionary Architecture?

Pros

Embraces unvertainty

Embraces change

Reduces risk

Cons

Assumes uncertainty

Assumes instability

Still has limitations

Where to Go Next

Books

Patterns of Enterprise Application Architecture

Clean Architecture

Domain-Driven Design

Dependency Injection in .NET

Pluralsite course

Domain-Driven Design Fundamentals

Domain-Driven Design in Practice

Modern Software Architecture

Microservices Architecture

Dependency Injection On-Ramp

Website

Martin Fowler: http://martinfowler.com

Greg Young: http://goodenoughsoftware.net

Udi Dahan: http://udidahan.com

출처

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

Test-Driven Development

Test Automation Pyramid

Pros and Cons

Test-Driven Development

Test-Driven Development is a software practice where we create a failing test first before we write any production code, and use this test to drive the design of the architecture.

1. Create a failing test for the simplest piece of functionality we need to create.

2. Get the test to pass (implement just enough production code to get that failing test to pass)

3. Improve the code (refactor our existing code)

4. Repeat 1~3 steps

TDD

Comprehensive suite of tests

Drives testable design

More maintainable

Eliminates fears to change

Types of Tests

What to test : Unit tests, Integration tests, Component tests, Service tests, UI tests

Why being tested : Functional tests, Acceptance tests, Smoke tests, Exploratory tests

How being tested : Automated tests, Semi-automated tests, Manual tests

Acceptance Tests

1. Eliminate user interface then replace to Acceptance Tests

2. Eliminate database then replace to in-memory Database

3. Eliminate dependencies in the infrastructure and cross-cutting concerns layer then replace to fake test doubles called mocks that act as surrogates for the real dependencies

Acceptance criteria should be written in the language of the business to describe business functionality that the application needs to provide.

Focus on the essential, and not implementation details

Minimize coded UI tests, Smoke test instead     

Minimize manual tests, Exploratory test instead

Why Create Testable Architecture?

Pros

Easier to test

Improves design

Eliminates fear to change code

Cons

Higher up-front cost

TDD requires discipline

Requires team buy-in

Demo

Uses NUnit, Moq, AutoMoq, SpecFlow

출처

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