Domain Driven Design (DDD)

2022/06/30 (新增連結)

基本概念

• Domain, Subdomain, Bounded Context, Problem/Solution Space in DDD: Clearly Defined

• DDD vs DDD : Domain-Driven Design vs Demo Driven Development, a case for the “Yes upfront design” approach

• Getting Started with Domain-Driven Design **

  • About Domain-Driven Design

  • Representing the Model

  • Ubiquitous Language

  • Strategic Design

    • Bounded Contexts

    • Context Maps

    • Patterns for context mapping

  • Modeling the Domain

    • Dealing with Structure

      • Entities

      • Value Objects

      • Cardinality of Associations

      • Services

      • Aggregates

    • Dealing with Life Cycles

      • Factories

      • Repositories

    • Dealing with Behavior

      • Specification Pattern

      • Strategy Pattern

      • Composite Pattern

  • Application Architecture

    • User Interface

    • Application

    • Domain

    • Infrastructure

  • Recently Added Patterns

• Domain-Driven Design in a nutshell

  • Domain-Driven Design is about shared understanding.

  • The ubiquitous language

  • Bounded context

  • Aggregates, entities, and value-types

  • Services

  • Evolution

• Domain-Driven Design: Everything You Always Wanted to Know About it, But Were Afraid to Ask

  • Strategic Design: Splitting your design so as to not lose your mind

  • Collaborative Modeling: Rich communication and effective collaboration

  • Tactical Design: The Nuts and Bolts of DDD

• Domain Driven Design (wikipedia)

• domain-driven design (ddd) vs Domain-Driven Design (DDD)

• DDD 101 — The 5-Minute Tour

• Domain Driven Design Quickly

• Domain-Driven Design – What is it and how do you use it?

  • Concepts

    • Context

    • Model

    • Ubiquitous Language

    • Bounded Context

  • Building Blocks

    • Entity

    • Value Object

    • Domain Event

    • Aggregate

    • Service

    • Repositories

    • Factories

• Basic concepts of Domain Driven Design

• Get your feet wet with domain-driven design: 3 guiding principles

  • Capture the domain model, in domain terms, through interactions with domain experts

  • Embed the domain terminology in the code.

  • Protect the domain knowledge from corruption by other domains, technical subdomains, etc.

• Why you need domain-driven design (even though you think you don't)

• Share Pie: The DDD Treasure Hidden in Plain Sight

• 為什麼需要 Domain-Driven Design

• Practical DDD, Part 1 — Setting The Right Foundations

• Book review: Learning Domain-Driven Design by Vlad Khononov

• Explain combining Domain-Driven Design and Databases

Architecture

• Architecture Ownership Patterns For Team Topologies. Part 1: A Business Architecture Model

• Domain-Driven Hexagonal Architecture for JavaScript / TypeScript Developers

• Hexagonal architecture and Domain Driven Design

• What is domain-centric architecture?

• Domain driven architecture in the frontend (I)

• Domain driven architecture in the frontend (II)

• Architecture & DDD Kata: Online Car Dealership

  • The first part is creating a business model

  • The second part explores the company’s domain landscape (business processes, user journeys, products, systems, etc) using an event storm

  • The third part focuses on strategy — how different domains connect to the business strategy.

  • The final part of the kata provides a space for trying out message flow modelling.

Domain

• What is a Domain?

• Strategic Domain-Driven Design Kata: Delivericious

  • Part 1: Domain discovery

  • Part 2: Designing domain boundaries

  • Part 3: Choosing core domains

  • Part 4: Designing domain collaboration

• From Domains to Value Streams

• Turning Domain Discovery into Product and Organizational Improvements with a DDD Exemplar

Bounded Context

• Domain-Driven Design: Things to Remember When Building a Bounded Context

• Bounded Context Canvas Recipe: Use Case Swimlanes

• Domain-Driven Design: When is a Bounded Context no longer a Bounded Context?

Event Storming

• Introducing Event Storming (by Alberto Brandolini)

• Big Picture Event Storming

  • Event storming is a brainstorming workshop where product delivery participants with different expertise share their part of business knowledge expressing it on colorful sticky notes on a wide wall.

    • Any event storming starts with collecting the knowledge about your business, expressed in a form of Domain Events, which are stuck to the wall in time order from left to right.

      • A Domain Event is any event that is important for your business and makes an explicit impact on it.

    • Definitions are used to highlight business terms.

    • After you feel that most of the domain knowledge is reflected in events on the wall, focus on the Commands that trigger appropriate Events.

      • A Command is a message that represents the intention of a user, and could be expressed as an action, like Request Booking, Cancel Booking, Request refund, etc.

    • The Actor triggers a particular command

    • Policy artifact is used to document conditions and policies for events to happen

    • Comments

      • Sometimes you may need to add a description in a free form to something in the domain. That is what the Comments artifact is used for.

    • Improvements & Opportunities

      • One of the important advantages of the event storming’s interactive format is that it helps to identify inconsistencies, points for improvements, and find new opportunities for business domain development.

    • Systems

      • A System could be anything that provides solutions in your business domain

• Event Storming For Rapid Domain Learning

  • As a (Persona), I want (Command), so that (Domain Event)

• From Event Storming to User Stories

  • One way of looking at it is to start from the key domain events and commands identified during the Event Storming workshops. Many of these events/commands are related to user actions and can be treated as the backbone in a User Story Map, i.e., they can be the epics or user journey steps in the User Story Map.

• Event Storming Workshop Cheat Sheet

參考資料

• DomainDrivenDesign.org

  • Architecture DDD

    • Domain-Driven Design is about language and communication

    • What does this give us in the end:

      • almost all team members can read the project code;

      • the statement of tasks becomes more explicit;

      • business logic bugs become easier to find;

  • The main goal of Domain-Driven Design

  • So why DDD?

  • Domain Driven Design

  • Real constructors

  • Value of Domain Driven Design

• 搞笑談軟工 (Teddy Chen)

  • [還少一本書] Domain-Driven Design

  • BDD（9）：DDD乍現

  • 從領域驅動設計看Tennis Kata（上）

  • 從領域驅動設計看Tennis Kata（下）

  • 落實TDD的三個難題（上）：領域模型與軟體架構

  • 落實TDD的三個難題（中）：通用語言的建立

  • 落實TDD的三個難題（下）：技術能力的精進

  • 學習DDD有感

  • 如何閱讀模型驅動設計建構區塊的模式語言

  • 領域邏輯與應用邏輯

  • CRUD魔咒

  • 領域事件的發送與接收（上）

  • 領域事件的發送與接收（下）

  • 領域事件幫你切割使用案例

• 領域驅動設計學習筆記 (Teddy Chen)

  • 領域驅動設計學習筆記（1）：學習的切入角度（上）

    • 在DDD中則是透過開發人員與領域專家密切合作，將問題領域（problem domain）切割出子領域（subdomain），然後決定每個子領域的Bounded Context作為塑模的邊界範圍。在這個Bounded Context中，大家都用相同的語言來溝通需求、設計以及實作。這種語言在DDD中稱為通用語言（Ubiquitous Language）。

  • 領域驅動設計學習筆記（2）：學習的切入角度（下）

    • DDD在本質上是一種很適合敏捷開發的方法，DDD首先將一個大系統切分成若干個Bounded Context，每一個Bounded Context只交給一個團隊開發（一個團隊可以同時負責好幾個Bounded Context的開發工作）。每個Bounded Context之間有著清楚的介面，可以獨立運作。這一點對於將敏捷開發拓展到大型軟體專案上有著天生的自然對應關係。

  • 領域驅動設計學習筆記（3）：實驗計畫

  • 領域驅動設計學習筆記（4）：Bounded Context

    • Bounded context的想法就是不要把一整個大系統視為一個context，而是依據「某種方式」把整個大系統分成若干個bounded context（有界限的context）

      • 每一個bounded context都有屬於自己的domain model

  • 領域驅動設計學習筆記（5）：Aggregate (上)

  • 領域驅動設計學習筆記（6）：Aggregate (中)

  • 領域驅動設計學習筆記（7）：Aggregate (下)

  • 領域專家X

    • 落實BDD/SBE的困難

    • 落實DDD的困難

      • 落實DDD的困難之一在於如何找到一個「合適且完整的系統當作例子？」

  • 領域事件幫你切割使用案例

  • 領域驅動設計學習筆記（8）：幫Event Handler取個好命字

  • 領域驅動設計學習筆記（9）：Query和Read Model

  • 領域驅動設計學習筆記（10）：實作Repository

  • 領域驅動設計學習筆記（11）：Bounded Context（上）

  • 領域驅動設計學習筆記（12）：Event Storming與User Story

  • 領域驅動設計學習筆記（13）：幫Event Storming加上使用者介面

  • 領域驅動設計學習筆記（13）：什麼時候不要用領域驅動設計

  • 領域驅動設計學習筆記（14）：依據領域事件流動方向調整Bounded Context的依賴關係

  • 領域驅動設計學習筆記（15）：拿掉領域事件所造成的跨Bounded Context原始碼依賴關係

  • 領域驅動設計學習筆記（16）：領域模型要放什麼東西？

  • 領域驅動設計學習筆記（17）：與外部系統的互動

  • 領域驅動設計學習筆記：用合約彌補測試案例的不足（上）：撰寫合約

  • 領域驅動設計學習筆記：用合約彌補測試案例的不足（下）：透過合約發現系統行為缺陷

  • 領域驅動設計學習筆記（14）：透過合約讓領域模型與通用語言更精確

  • 領域驅動設計學習筆記（15）：領域專家缺貨

  • 領域驅動設計學習筆記（16）：學DCI，重構Aggregate ，Part 1

  • 領域驅動設計學習筆記（17）：學DCI，重構Aggregate ，Part 2

  • 領域驅動設計學習筆記（18）：學DCI，重構Aggregate ，Part 3

  • 領域驅動設計學習筆記（19）：DDD需要套用Unit of Work (UoW) 設計模式嗎？

  • 領域驅動設計學習筆記（20）：再談Aggregate Root實作

  • 領域驅動設計學習筆記（21）：貧血模型與充血模型（上）

  • 領域驅動設計學習筆記（22）：貧血模型與充血模型（下）

• Think in Domain-Driven Design

  • 關於 Domain-Driven Design 以及他的魅力

  • DDD 學習路徑與資源分享

  • 戰略設計：運用 Domain, Subdomain 與 Bounded Context 打造藍圖

  • 戰略設計：Bounded Context 深度解析

  • 戰略設計：來聊聊 Bounded Context 的世間情 -- Context Mapping

  • 戰略設計：重點回顧以及比喻

  • Event Storming Part 1 - 簡介與事前準備

  • Event Storming Part 2 - 風暴展開

  • Event Storming Part 3 - 軟體設計

  • Event Storming Part 4 - 可以做的更好

  • 軟體架構淺談

  • DDD 架構： 分層式架構與依賴反向原則

  • DDD 架構： 整合 Clean Architecture

  • DDD 戰術設計： Entity 概念與實作

  • DDD 戰術設計：Value Object 概念與實作

  • DDD 戰術設計：組織你的幫派 Aggregate 聚合設計

  • DDD 戰術設計：Aggregate 聚合設計 (續)

  • DDD 戰術設計：工廠模式

  • DDD 戰術設計：Repository 資源庫

  • DDD 戰術設計：Application Service

  • DDD 戰術設計：Application Service 2 - 結合 TDD/BDD

  • DDD 戰術設計：Application Service 3 - 結合 TDD/BDD (續)

  • BDD - 如何寫出好的 Gherkin 語法展示你的 Specification By Examples

  • DDD 戰術設計：Domain Event 領域中的重要事件

  • DDD 戰術設計：Domain Service

  • DDD 戰術設計：Module

  • DDD 戰術設計：Bounded Context Integration

  • DDD 實戰：為 Legacy 引入 DDD - 上篇

  • DDD 實戰：為 Legacy 引入 DDD - 下篇

  • DDD TypeScript 模板

• Silver bullet for middle+ frontend projects: DDD-like structure

• The Domain Driven Design’s Missing Pattern : Domain Services

DDD for Micro-services

• Domain-Driven Design in the era of Microservices

• Strategic Domain-Driven Design

• Big Picture Event Storming

Event Driven

• Events-First Domain Driven Design