Clean架构中不好的部分 -James Hickey

Clean架构中不好的部分 -James Hickey

Clean体系结构是设计软件系统的常用方法。但是，有些问题可能会给您带来弊大于利的后果……“Clean架构”是Bob Bob叔叔在他的书中自然地提出的一种软件体系结构与架构模式。这是构造软件代码的一种方法，它是六角形体系结构的一个示例。

端口和适配器
六角形体系结构（也称为“端口和适配器”体系结构）的基本思想是，领域逻辑和域对象位于应用程序的“中心”。其他问题，如持久性，缓存等，都被视为域代码的附件或“适配器”。

通常，这是通过让您的域代码将对这些基础结构或应用程序级代码的任何需求公开为接口来完成的。
例如，这在概念上类似于我们如何设计计算机。计算机具有专用的核心用途，但允许外部设备通过某种接口（USB端口，HDMI端口等）“插入”。

Clean架构原理
Clean体系结构有许多原则，我将在这里总结：

1. 独立于框架
2. 独立于UI
3. 独立于数据库
4. 独立于任何外部机构

乍一看，我认为大多数软件开发人员都会同意这些原则。来自Clean架构和域驱动设计的最重要原则是使域对象和域逻辑与其他问题分开。
DDD一书：

我们需要使域对象与系统中的其他功能脱钩，因此我们可以避免将域概念与仅与软件技术相关的其他概念混淆，或者避免在整个系统中完全看不到域。

如何倾向于从概念模式过渡到实施
大多数开发人员从思考这些原理到将其实现到实际软件项目中的方式存在问题。
典型的结构是创建处理以下内容的项目或库：

• 基础设施层

我们倾向于采用这些概念，并且“一对一”地将它们实现为专用的.NET项目，Java包等。我认为，这种从概念上的思维转变成将其作为构建代码的特定“蓝图”的方式的做法是错误的。

在我曾任职的公司之一中，我引入了Clean体系结构，这是开始改进开发流程，开发速度和产品质量的许多方法之一。我们为新功能实施了Clean架构。虽然这是方式优于现有的公约和架构，但是最大的问题之一是上下文切换。

上下文切换
例如，如果您正在使用某个功能，并且需要处理数据访问，域或应用程序逻辑的任何组合，则必须将上下文完全切换到另一个软件项目中，变成一个完全不同的文件夹结构。
这似乎效率低下。
我决定将与特定功能相关的所有内容放到同一文件夹中，带来的好处多于没有。
在尊重依赖规则的同时，这个想法是遵循高度凝聚力原则的逻辑结论：在一起改变的事物应该在一起生活。但是，这是否会引起担忧？应用层，领域和数据库逻辑放在同一个地方？如果您了解高内聚和松散耦合的原理，那么这应该不是问题。您仍然可以在概念上实现“端口和适配器”，但是在每个单独的功能内。例如，我采用的典型方法是这样的：

从具有多个功能或产品的角度看待它，它看起来像这样：

请注意，我已将“应用”和“领域”层合并在同一存储文件夹中。

垂直切片
我是通过使用松散耦合和高内聚性的原理自行提出这种方法的。当我迷失于这种思维方式时，我遇到了通常被称为“垂直切片”架构的事物。据我所知，吉米·博加德（Jimmy Bogard）负责编纂这种方法。
以我的经验，这种方法比较简单。在应用程序中添加或更改功能时，通常会触及应用程序中的许多不同“层”。我正在更改用户界面，向模型添加字段，修改验证等等。而不是跨层耦合，我们沿着切片垂直耦合。 最小化切片之间的耦合，并使切片中的耦合最大化。
https://jimmybogard.com/vertical-slice-architecture/
它不是从技术角度（例如域与基础结构与应用程序逻辑）着眼于关注点分离，而是从反映业务域的功能的角度出发。同样，毫无疑问，保持数据访问与域逻辑分离是关键。

banq注：垂直切片类似微服务：
https://www.jdon.com/54049