这篇对话主要讨论了六边形架构以及它与MVC、SOA架构的区别，特别是关于领域模型和业务逻辑的处理方式。以下是对话的大白话整理：
- 背景：对话者正在研究六边形架构，之前有MVC和SOA架构的经验。在SOA架构中，通常会使用“贫血模型”（POJOs），即领域对象（如Cart）只是简单的数据容器，业务逻辑放在服务类（如CartService）中。这种方式对单元测试很有好处。
- 疑问：对话者想知道，在六边形架构中是否还能继续使用这种“贫血模型”的开发策略，或者是否需要改变方式，将业务逻辑直接放到领域类中（即“富模型”）。
- 六边形架构的核心：六边形架构的重点是将领域逻辑与技术细节（如数据库、框架等）分离。因此，无论使用贫血模型还是富模型，只要遵循这种分离原则，都可以应用六边形架构。
- 框架的影响：对话者提到，像Spring这样的框架通常会强制使用依赖注入（DI）和贫血模型，这可能会导致领域对象缺乏业务逻辑。对话者对此感到困惑，甚至质疑为什么还要使用面向对象语言，因为领域对象往往是“虚拟”的，业务逻辑都放在服务类中。
- Ruby on Rails的经验：对话者提到，Ruby on Rails的框架理念不同，模型类通常也很“贫血”，但这种方式对单元测试很有帮助，并且避免了业务逻辑的混杂。
- 总结：六边形架构并不关心你是用贫血模型还是富模型，它的核心是将领域逻辑与技术实现分离。你可以继续使用SOA架构中的贫血模型，只要确保领域逻辑与技术细节分开即可。