(Modern Software Architecture) Domain-Driven Design (DDD)

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