這篇對話主要討論了六邊形架構以及它與MVC、SOA架構的區別，特別是關於領域模型和業務邏輯的處理方式。以下是對話的大白話整理：
- 背景：對話者正在研究六邊形架構，之前有MVC和SOA架構的經驗。在SOA架構中，通常會使用“貧血模型”（POJOs），即領域物件（如Cart）只是簡單的資料容器，業務邏輯放在服務類（如CartService）中。這種方式對單元測試很有好處。
- 疑問：對話者想知道，在六邊形架構中是否還能繼續使用這種“貧血模型”的開發策略，或者是否需要改變方式，將業務邏輯直接放到領域類中（即“富模型”）。
- 六邊形架構的核心：六邊形架構的重點是將領域邏輯與技術細節（如資料庫、框架等）分離。因此，無論使用貧血模型還是富模型，只要遵循這種分離原則，都可以應用六邊形架構。
- 框架的影響：對話者提到，像Spring這樣的框架通常會強制使用依賴注入（DI）和貧血模型，這可能會導致領域物件缺乏業務邏輯。對話者對此感到困惑，甚至質疑為什麼還要使用面嚮物件語言，因為領域物件往往是“虛擬”的，業務邏輯都放在服務類中。
- Ruby on Rails的經驗：對話者提到，Ruby on Rails的框架理念不同，模型類通常也很“貧血”，但這種方式對單元測試很有幫助，並且避免了業務邏輯的混雜。
- 總結：六邊形架構並不關心你是用貧血模型還是富模型，它的核心是將領域邏輯與技術實現分離。你可以繼續使用SOA架構中的貧血模型，只要確保領域邏輯與技術細節分開即可。
簡單來說，六邊形架構的核心思想是“分離”，至於業務邏輯放在哪裡（領域物件還是服務類），可以根據專案需求選擇，但要注意不要讓技術細節侵入領域邏輯。