D25 ch 22 整潔的架構

第 12 屆 iThome 鐵人賽

DAY 25

自我挑戰組

30天｜入門NestJs連載學習筆記系列第 26 篇

12th鐵人賽

azsx96385

團隊Outcome First

2020-10-10 01:38:04

867 瀏覽

分享至

1. 架構都有同個目標-關注點分離
- 透過將軟體分層，實現關注點分離，每個業務規則至少有一層屬於他們，使用者及系統也至少有一層屬於他們
- 共同特徵
  1. 獨立於框架
    好的架構不依賴於現有強大的軟體程式庫，它允許你使用這樣框架作為工具，而非強迫你將系統塞進入有限約束中
  2. 可測試
    業務規則可以在沒有ＵＩ、資料庫、web伺服器或其他外部元素的情況下，進行測試
  3. 獨立於ＵＩ
    無需更改系統其他部分，ＵＩ也可以很輕易做更改，ex. web → APP
  4. 獨立於資料庫
    你的業務規則不綁定資料庫，你可以隨意將Mongo\Bigtable\couchDB抽換成Oracle\SQLserver
  5. 獨立於任何外部代理
    業務規則對於外界介面一無所知
1. 依賴規則-原始碼依賴關係只能指向內部，朝向更高層級策略
- 內圈是策略，外圈是機制
- 越內圈軟體，層次越高，越外圈，層次越低
- 內圈沒有任何東西可以對外圈事情有所了解
- 外圈宣告名稱不能在內圈程式碼中出現（函式、類別、變數、任何被命名之軟體實體）
- 外圈宣告的資料格式不應該被內圈使用，尤其是格式是由外圈中框架所產生，內圈不應該被外圈任何東西影響
- 實體層
  - Entity 封裝了企業級的關鍵業務資料，當外部變化，實體曾是最不可能被改變的
- 使用案例層
  - 使用案例層，包含應用程式特定的業務規則，封裝並實作系統所有使用案例
  - 這些使用案例編排實體之間的資料流，並指揮這些實體使用他們的關鍵業務規則，來實現使用案例的目標
- 介面轉接層
  - 介面轉接層，的軟體是一組轉接器，可以將資料從最適合於使用案例和實體的格式→轉換→最適合某些外部代理（ex. DB or web)的格式
  - 介面轉接層，包括GUI的MVC架構、表示器（presenter)、視圖、控制器controller
  - 模型 model 可能只是資料結構，他從控制器傳給使用案例，並且之後還會從使用案例回傳給表示器（presenter)和視圖（view)
  - 在介面轉接層，資料從最適合實體和使用案例的形式，轉換為最適合正在使用的任何持久性框架（ex. DB )
  - 在介面轉接層，之內的所有程式碼都不應該對於資料庫有所暸解
  - 任何其他必須將資料從外部格式（ex. 外部服務）轉換為使用案例和實體所使用的內部格式轉接器，也屬於這一層
- 框架和驅動層
  - 框架和驅動層，通常由框架和工作組成(ex. 資料庫和web框架），一般來說，我們不會在此寫太多程式碼
  - 框架和驅動層是所有細節的去處，web是細節，資料庫是細節，我們將這些東西放最外層，因為他們不會有什麼危害