iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 25
1
    1. 架構都有同個目標-關注點分離
    • 透過將軟體分層,實現關注點分離,每個業務規則至少有一層屬於他們,使用者及系統也至少有一層屬於他們
    • 共同特徵
      1. 獨立於框架
        好的架構不依賴於現有強大的軟體程式庫,它允許你使用這樣框架作為工具,而非強迫你將系統塞進入有限約束中
      2. 可測試
        業務規則可以在沒有UI、資料庫、web伺服器或其他外部元素的情況下,進行測試
      3. 獨立於UI
        無需更改系統其他部分,UI也可以很輕易做更改,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是細節,資料庫是細節,我們將這些東西放最外層,因為他們不會有什麼危害

上一篇
D24 無暇程式碼-CH20 商業邏輯
下一篇
D25 ch 22 整潔的架構
系列文
30天|入門NestJs連載學習筆記26
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言