分層
關於遺留系統會遇到幾個狀況，是因為隨者發展會遇到幾個以下
- 升級
- 新功能
- 修復BUG
系統重構的目的：是為了修改越來越容易，做不到這一點就是失敗。
筆者常用在ASP.net MVC分層架構狀況。
再來如果是筆者的API例子的話，如圖：
其實也是跟上面的很接近，但是這樣階層性架構多少還是有點問題，但是如果階層性架構部分，寫得好，一樣也是擁有高品質和穩健的架構。
接者來說說關於筆者常用的分層結構說明
Service ：是整個系統核心，專門開發編寫業務程式，他的職責是、資料檢驗、邏輯判斷，條件約束，業務操作，是專門實現領域操作的地方，在書籍來說叫做領域層，也可以稱呼業務層，隨系統的業務層，會對應DTO的物件或是值物件，來專門適應新需求。
Repository ：專門稱呼持久層，資料存取層，是專門對DB操作曾、刪、改、查操作。
Model：筆者會擺放關於Entitie跟RequestViewModel跟ResponseViewModel，原因是資料存取用Entitie，若是API的狀況下，因為API有Request和Response的參數，這邊的用途其實也是跟DTO一樣，沒有任何行為的物件，其實也是貧血模型，稍後會來講到貧血模型部分。
Common：筆者會比較常常用來當作是放公用類別，例如這個是Email或是其他常用的函數處理，就會放在這一層。
關於合理的分層架構?
什麼層級的需求變更就去修改什麼樣的層級程式，例如：資料變更的時候就去改Repository，業務需求的部分就改Service層，若是API請求的參數或是資料表存取的結構變更就改Model層。
最頻繁修改地方或是調整地方，在系統開發中，筆者經驗最常遇到的就是業務程式的修改與調整。
業務核心設計的重構就必要時候就要發揮DDD的思想(以後再提和寫這系列)。
老E隨手寫