# Doamin

1. 要處理的商業邏輯
2. 問題領域
3. 專業領域需求/問題
4. 商業範圍相關問題
5. 客戶的範圍

#
1. Problem Domain
1. 發生在真實世界裡面
1. 問題發生在各不同專業的問題中
1. Bank Domain >>>> Kaban Dmain
1. Solution Domain
1. 建立模型產生軟體解決問題領域
1. 建立Domain Model

# QA
1. Domain 有大有小
1. 對於客戶應該如何界定通用Doamin的大小 => 每個領域不一樣無法界定通用Domain

# Domain Modeling
1. 傳統常見的模型為資料模型而非領域模型
1. 問題領域中解決問題的行為

# Domain Model 是不是越真實越好
1. `夠用就好`
2. Model會不斷的改變
3. 能夠解決問題的相對模型就好了

# Driven
* 推動解決問題的方式
* 了解問題領域模型後推動的開發方式

# Design
1. 規範
2. 把Domain Modle實作出來 => coding
3. UML diagon
4. System Architecture
6. 克里斯多福(design pattern 提出者) ： 設計就是決定`From` 與`Context` 的邊界
7. From : 產品
8. Context : `Form` 以外的東西
9. Form是問題的解答，而Context限定了問題[link](http://teddy-chen-tw.blogspot.com/2013/06/blog-post_25.html?fbclid=IwAR3nFkZSaeiBOxHpYh_meu3szdNcsJp3WyAphavKXp-vYXYpWMhwqBn2Cb0)

# Forces
1. 變因
2. 作用力
3. 約束條件
4. Force越多，越成型，越精確
5. 沒有Force就沒有問題

# What is Good Design
1. fitness - 合適性
1. Solution 需要放在context 下討論才知道適不適合

# DDD
1. 建模 - Collaborative Modeling
2. 戰術設計 - Stratic Design
3. 程式 - Modeling in Code

# 通用語言 (Ubiquitous Language)
1. 一小群人，共通的語言
1. 以Problem Domain 術語為主
1. 程式要與分析的Doamin Model 一樣

* Domain Expert 為領域中，很瞭解該領域或商業邏輯的人
* Domain Expert 不需要很懂 UI/UX

# Bounded Context
1. 類似PackageName
2. 可以有相同名稱的Model
3. 可達到Localization

# OOAD
1. 不停的做 Model Translate

`*不要做Model Translate 只要做Domain Model `

1. Strategic Design <=> Analysis
2. Tactical Design <=> Design

# Patten Language
1. 用各種Patten 串連後組成Solution

# Entites
1. 有id 的物件

# Value Object
1. 可以使用context 分別的物件

# Service
1. 沒有狀態只有function的class

# Aggregates
1. a group of object
2. client 只能透過 Aggregate Root 操作 Aggregate 物件

# 看板

1. 訊號卡片
2. 視覺版

# 視覺化

1. 畫工作流程
2. 工作卡片視覺化

# 限制WIP

1. Walk in Progress(Process)
2. 半成品
3. 限制工作項目

# Manage Flow

1. 管理工作流
2. 檢查排除阻礙，讓工作快速流動

# Event Stoming
1. Big Picture
2. Process Modelling
3. Software Design

## QA
1. Event Stoming 非無中生有，而是慢慢迭代
2. Event Stoming 順序非絕對，而是依照現實中通常的順序

## Big Picture

### 如何建立邊界
1. 內部的部門會形成天然的邊界
2. Component Team
3. Feature Team

### Bounded Context
1. Core Domain
2. Generic Domain (任何系統都會存在的項目)
3. Supporting Domain ()

==* 只有Core Domain 要使用DDD，其餘不一定使用==

## Process Modelling

##
1. 用Specification By Example

### Aggrate
1. 如果 Aggrate 有多個，已選擇小的為主
2. 跨 Aggrate 查詢時，使用 Association class (MappingTable)

## CQRS

### Command
1. 會改變系統狀態的操作，但不會回傳值
1. 這些命令會變更系統的狀態。(by 微軟)

### Query
1. 會回傳值的操作，但不會改變系統狀態
2. 這些查詢會傳回結果，而不會變更系統的狀態，而且它們沒有任何副作用。(by 微軟)

[微軟CQRS範例](https://docs.microsoft.com/zh-tw/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/)

==*Event Stoming 沒有描述Query & Ui , 因此使用CQRS 中的Query 代替描述==
==*Board 關係 when creat Tag==

==CQRS不一定只能放在DDD的DoaminModle，可以在Any Where，只要是合適的==

### 跨 bounded context 傳遞資料
1. 使用json 互相傳遞，因為 bounded context 之間沒有共通的Dto

### 何時決定架構## Context map pattern
- anticorruption layer, 防腐層: 避免Bounded Context之前互相汙染。adapter pattern，主要作用是轉譯不同Bounded Context間的語言。
- separate ways:如果合作成本太高，斷開兩個Bounded Context的關係。
- open host service:如果開放別人存取的資料，用公開的標準讓人去存取。
- shared kernel, 不同Bounded Context共用的domain model
- customer/supplier teams:上下游關係(單向依賴)
- Conformist:上下游關係時，下游直接遵循使用上游的語言

1. 當不做決定的時候成本大於做決定的時候

### 軟體修改成本
1. 軟體修改成本應與Scope有關，而與時間無關 (敏捷期望)

### Service
1. 可以在UserCase 層 (Application Layer)
2. 可以在Entite 層 (因為有可能該方法會是全域共用)

### Policy
1. 在UserCase層，因為會經常改變

## Clean Architecure
1. Entites layer (!= DDD的 Entites)
2. Entites & UserCase 與外部無相依性
3. 使用依賴反轉解決相依性問題
4. 一旦Entity要跨出 [Entities+UserCase] 就要轉為其他Dto

==Clean Architectur處理依賴反轉==

==使用CRUDRepository做Aggrate與DBModel 做跨層處理==

## 資料庫處理

1. Respority中，會使用Mapper 處理 Domain Model <=> DBModel 資料轉換

## Event Sourcing
1. 直接將Aggrate 存入
2. 可以朔源
3. 效能差

## Context Map
1. 使用adpater 串接兩個Context
2. 位置應該在Interface層

## Context map pattern
- anticorruption layer, 防腐層: 避免Bounded Context之前互相汙染。adapter pattern，主要作用是轉譯不同Bounded Context間的語言。
- separate ways:如果合作成本太高，斷開兩個Bounded Context的關係。
- open host service:如果開放別人存取的資料，用公開的標準讓人去存取。
- shared kernel, 不同Bounded Context共用的domain model
- customer/supplier teams:上下游關係(單向依賴)
- Conformist:上下游關係時，下游直接遵循使用上游的語言

## DDD + CQRS + Clean Architecure 開發流程(個人看法)
1. 可先將專案大致分為以下幾個資料夾

        - Src
            - Application
                - Adapter
                    - IRepostory
                - UserCase (CQRS)
                    - Command
                    - Query
                    - EventHandler
            - Domain
                - Entity
                - ValueObjects
                - DoaminEvent
                - Enums
                - Exceptions
            - Infrastructure(Providers)
                - Repost
            - Presenter
                - WebUI
                - WebAPI
        - Tests
            - Application
                - Adapter (Interface)
                    - IRepository
                - UserCase
            - Domain
                - Entity
                - ValueObjects
                - DoaminEvent
                - Enums
                - Exceptions
            - Infrastructure
                - Repository
            - Presenter
                - WebUI
                - WebAPI

2. 由Event Stoming 對照寫出 TestCase
3. 可先將所有實作寫在UserCase之中
4. 測試全部通過後，再依分層切割功能項目

### C# 參考資料
[jasontaylordev/CleanArchitecture](https://github.com/jasontaylordev/CleanArchitecture)