您所遇到的最流行的代码排列方式是什么？我最常看到的一种是按技术堆栈中的层将所有类分组。因此，在 MVC 风格的系统中，所有控制器都在一起，所有服务都在一起，所有存储库都在一起，所有 POJO 在一起等等。让我们称这种约定为组织代码的“堆栈”风格。

其实我感觉这种方式不太好，接下来谈一下原因。

不恰当的抽象

人们不会按堆栈层阅读代码。从来没有人说“给我展示这个系统的所有 API”或“给我这个系统触发的所有查询”。人们沿着域边界阅读代码。例如在酒店管理系统中，人们会考虑房间、客人和价格等。

由于“堆栈”风格的代码是按照技术层组织的，因此很难从系统在存储库中的方式来理解系统的逻辑模型。“堆栈”风格暴露的边界是技术层。我们无法从这段代码中理解“名词”以及它们之间的关系。你必须为此深挖一层。对于阅读代码的新人来说，这种对“逻辑”结构的混淆是一个巨大的摩擦源。

在酒店管理示例中，“实体样式将所有与客人相关的代码（不考虑技术层）放在一个包中，所有与房间相关的代码都放在另一个包中，依此类推。这些包中的每一个都可以在“堆栈”样式中拥有自己的内部组织，或者只有几个处于同一级别的类。这使得在一个地方轻松找到与客人相关的所有内容。

凝聚力差

“堆栈”排列方式的另一个常见论点是它将单独的模块放在技术堆栈的不同层。例如，控制器与服务、服务与存储库等明显分离。要在技术堆栈的不同级别找到类，您需要转到代表这些级别的包。这鼓励了不同层之间的解耦。

这个论点的问题在于它专注于耦合，而忽略了另一个关键属性——内聚。在哪些类之间我们想增加内聚性，哪些类我们想减少耦合？由于所有服务都位于一起，我们是否可以说它们高度内聚但与它们的模型类或存储库分离是可以的？我们是否可以让所有存储库相互高度依赖，但与服务层的业务逻辑解耦？显而易见的答案是否定的！这种代码将是教科书般的大泥球。将这样的系统重构为更小的系统绝对是一场噩梦，因为您必须在技术堆栈的每一层解耦类。它违背了使用 MVC 风格的全部目的。

“实体”风格 OTOH 促进了凝聚力，同时仍为技术堆栈风格解耦留出空间。如果所有与酒店相关的类都相互依赖（技术上或概念上），这是可以的，因为它们无论如何都形成了一个单一的工作单元。它还使未来的重构更容易，因为逻辑边界比“堆栈”风格更清晰。

很难改变

为了在以“堆栈”风格组织的代码库中进行任何有意义的更改，开发人员必须跨越多个包。例如，要向实体及其 CRUD API 添加新字段，将修改所有包。这会造成认知负担，因为开发人员必须修改许多“事物”而不是单一的逻辑事物。

在“实体”中，如果你改变了一件事情，你只会在一个逻辑边界上做出改变。这使得对它们的更改更容易，因为如果使用单个实体，我们只在代码库的一小部分工作。如果你跨越顶级包，你就是在跨越定义的逻辑结构，这会提醒你潜在的与耦合相关的注意事项。

限制设计选择

由于代码是按技术堆栈或功能组织的，它限制了人们思考系统设计的方式。例如，由于业务逻辑应该进入“服务”，开发人员拒绝使用正确的设计结构，宁愿将所有内容都塞进服务中，从而创建数千行的噩梦类。即使他们使用良好的设计原则，代码的组织也会抵制他们，因为每个新的“类型”都必须在一个独特的包中。如果我想在不同的服务中使用工厂模式，那么我必须发明一个名为factory 的全新包层次结构，此后所有工厂都应该去那里，无论它们是否彼此有任何关系。

正如我之前提到的，“实体”不假设每个逻辑包在内部是如何分组的。它可以是堆栈样式，也可以根据需要拥有任意多种类型的包，而不会影响在另一个实体的包中所做的选择。

这里的一个问题可能是如何组织跨越实体的事物。例如，在多个实体上运行的工作流。这两种风格都没有一个简洁的答案，但 IMO 的“实体”风格在这方面做得更好，因为它强制在所有实体包之外创建一个新包。这突出表明工作流是一个新概念，并且可能是应该独立开发的系统边界。这个想法是将相似的概念组合在一起，但不受单一概念约束的事物仍然可以在基础上拥有自己的逻辑。

建议

一种更好的组织代码的方法，可以按它所代表的逻辑实体对其进行分组。让我们称之为组织代码的“实体”风格。这个想法是确保与单个概念相关的所有类保持在一起。通过将逻辑实体放在首位，我们正在针对人类理解进行优化（编译器不关心您将哪个类放在哪里）。凭借代码的呈现方式，开发人员被推动对实际系统边界所在的位置做出更明智的选择。不是在SomethingRepository和SomethingElseRepository之间，而是在Something和SomethingElse之间作为概念。

现在让我们了解为什么我认为实体模型比堆栈模型更好。