Clean體系結構是設計軟體系統的常用方法。但是，有些問題可能會給您帶來弊大於利的後果……“Clean架構”是Bob Bob叔叔在他的書中自然地提出的一種軟體體系結構與架構模式。這是構造軟體程式碼的一種方法，它是六角形體系結構的一個示例。

埠和介面卡

六角形體系結構（也稱為“埠和介面卡”體系結構）的基本思想是，領域邏輯和域物件位於應用程式的“中心”。其他問題，如永續性，快取等，都被視為域程式碼的附件或“介面卡”。

通常，這是通過讓您的域程式碼將對這些基礎結構或應用程式級程式碼的任何需求公開為介面來完成的。

例如，這在概念上類似於我們如何設計計算機。計算機具有專用的核心用途，但允許外部裝置通過某種介面（USB埠，HDMI埠等）“插入”。

Clean架構原理

Clean體系結構有許多原則，我將在這裡總結：

1. 獨立於框架
2. 可測
3. 獨立於UI
4. 獨立於資料庫
5. 獨立於任何外部機構

乍一看，我認為大多數軟體開發人員都會同意這些原則。來自Clean架構和域驅動設計的最重要原則是使域物件和域邏輯與其他問題分開。

DDD一書：

我們需要使域物件與系統中的其他功能脫鉤，因此我們可以避免將域概念與僅與軟體技術相關的其他概念混淆，或者避免在整個系統中完全看不到域。

如何傾向於從概念模式過渡到實施

大多數開發人員從思考這些原理到將其實現到實際軟體專案中的方式存在問題。

典型的結構是建立處理以下內容的專案或庫：

• 應用層
• 領域層
• 基礎設施層
• UI層

我們傾向於採用這些概念，並且“一對一”地將它們實現為專用的.NET專案，Java包等。我認為，這種從概念上的思維轉變成將其作為構建程式碼的特定“藍圖”的方式的做法是錯誤的。

在我曾任職的公司之一中，我引入了Clean體系結構，這是開始改進開發流程，開發速度和產品質量的許多方法之一。我們為新功能實施了Clean架構。雖然這是方式優於現有的公約和架構，但是最大的問題之一是上下文切換。

上下文切換

例如，如果您正在使用某個功能，並且需要處理資料訪問，域或應用程式邏輯的任何組合，則必須將上下文完全切換到另一個軟體專案中，變成一個完全不同的資料夾結構。

這似乎效率低下。

我決定將與特定功能相關的所有內容放到同一資料夾中，帶來的好處多於沒有。

在尊重依賴規則的同時，這個想法是遵循高度凝聚力原則的邏輯結論：在一起改變的事物應該在一起生活。但是，這是否會引起擔憂？應用層，領域和資料庫邏輯放在同一個地方？如果您瞭解高內聚和鬆散耦合的原理，那麼這應該不是問題。您仍然可以在概念上實現“埠和介面卡”，但是在每個單獨的功能內。例如，我採用的典型方法是這樣的：

從具有多個功能或產品的角度看待它，它看起來像這樣：

請注意，我已將“應用”和“領域”層合併在同一儲存資料夾中。

垂直切片

我是通過使用鬆散耦合和高內聚性的原理自行提出這種方法的。當我迷失於這種思維方式時，我遇到了通常被稱為“垂直切片”架構的事物。據我所知，吉米·博加德（Jimmy Bogard）負責編纂這種方法。

以我的經驗，這種方法比較簡單。在應用程式中新增或更改功能時，通常會觸及應用程式中的許多不同“層”。我正在更改使用者介面，向模型新增欄位，修改驗證等等。而不是跨層耦合，我們沿著切片垂直耦合。 最小化切片之間的耦合，並使切片中的耦合最大化。

https://jimmybogard.com/vertical-slice-architecture/

它不是從技術角度（例如域與基礎結構與應用程式邏輯）著眼於關注點分離，而是從反映業務域的功能的角度出發。同樣，毫無疑問，保持資料訪問與域邏輯分離是關鍵。

banq注：垂直切片類似微服務：

https://www.jdon.com/54049