干净的架构边界

例如如果您有一个使用 JSON 的休息控制器，并且此 JSON 包含一个日期字符串。然后控制器负责将字符串解析为日期对象，例如作为 ISO 日期，或者它可能会尝试解析不同的格式。当您将解析的日期对象传递给用例时，用例有责任验证此日期在用例的上下文中是否有效。例如。如果您有用例“ScheduleMeeting”，则日期应该在未来。

用例层应该抛出像 ScheduledTimeElapsedException 这样的业务异常。控制器层可以捕获此异常并决定要做什么，例如休息服务可能会返回 HTTP 状态代码和/或带有更详细描述的 JSON，也可能是国际化的描述，具体取决于请求客户端的语言设置。

存储库

存储库是网关吗？如果是，它适合哪一层？

存储库是用例需要从中获取实体并将实体放入其中的接口。

网关是一种实现，它知道如何联系外部服务或数据库以从中获取数据并将数据存储到其中。

假设我在 DB 上有两个实体，Department 和 Employee。业务规则是：“要创建一个部门，我也必须创建它的员工，而且只能通过部门”。这种情况我该怎么办？

是否应该创建两个存储库，因为我只能在创建部门时创建员工，所以我应该通过部门存储库调用员工存储库中的 create() 吗？

您应该应用接口隔离原则并创建特定于用例的存储库接口。这个接口应该只定义用例需要的方法。由于业务规则是创建两者，因此该界面可能如下所示。

public void MyUseCaseRepository {
    public void persistDepartment(Department dep,List<Employee> employees);
}

如果你应用接口隔离原则，下面的其他问题也应该得到回答。

我是否应该只创建一个用例并创建一个网关来编排存储库？

然后实现可以负责存储两者或不存储。

您现在可能会想“但后来我将业务逻辑移到了网关中。”。阅读我对问题 Should Repositories Throw Domain Errors 的回答。

还有关于存储库，我可以通过存储库调用用例吗？这让我很困惑，因为理论上Usecase和repository都会有接口，而且它的实现可以在同一层，所以有什么规定吗？

简洁的架构并没有真正对此做出声明。存储库实现位于接口适配器层，就像控制器一样。因此理论上他们可以访问用例。但我认为这不是作者的意图。我认为 Bob 大叔认为它更像是六边形架构，存储库是适配器，而控制器是端口。我不会从存储库实现中调用用例。最后这个问题只能由作者来回答了。

DTO

它是否有第二个构造函数需要一个“输入”，并且这个构造函数填充相应的字段？

我猜您的意思是当您说“输入”时用例返回的 ResponseModel。

从架构的角度来看，这是可以的，因为 DTO 属于控制器或接口适配器层，因此依赖方向是正确的。

但是当 DTO 的构造函数读取响应模型并填充它的字段时，它也会将响应模型的值转换为它们的 DTO 表示。也许您想将这种转换与 DTO 本身分开，并将其放在可以单独测试的演示器实现中。

如果我必须创建三个“层”域，是否有任何规则？比如 DepartmentRequest、Department 和 DepartmentEntity？如果不是，我可以为一个实体只有两个或一个对象吗？

您可以在干净的架构中看到规则。依赖箭头从外层开始，在下一个内层结束。没有箭头指向例如从控制器层到实体层。因此，如果您对架构非常严格，控制器不应访问实体。

如果你把所有东西都放在一个对象里，例如Department 并且您几乎将其用于所有内容，例如作为 DTO，作为数据库实体和域实体，那么您将所有这些不同的职责结合起来。

因此，如果您修改数据存储在数据中的方式，您可以轻松破坏 DTO 表示，反之亦然。如果要修改业务规则，也可以轻松破坏数据库表示，反之亦然。最后，如果您修改业务规则，您还可以打破 DTO 表示。

这些对象看起来很相似，但它们的职责不同，因为它们服务于不同的客户端。因此，如果您将所有内容都放在一个对象中，您将违反单一职责规则。

我不能告诉你一次违反责任的所有影响，因为这远远超出了这个问题。

想想 Bob，如果软件环境/Lang 没有模块概念，他会不会使用这种模式？

架构就是架构，文件夹和模块不是架构，它们是权衡。模块可以帮助设计它，这样业务层就不能访问 jdbc 之类的东西，代价是更多的模块定义。

用例是应用程序的公共 api，因此验证在那里进行。用例应仅实现桥接模式中的桥接，桥接的另一端是例如一个存储库。

桥梁（例如接口和边界类）充满了需求。用例要求很高，可能需要 5 或 10 个不同版本的相同操作。它可以表示为 en Enum 或存储库中的 10 个方法，这些决定是权衡/风格/等。

控制器将验证请求是否有效（将它们视为超市中的钞票检查器）。但业务逻辑（POS）将验证优惠券是否有效以及价格折扣是多少。

硬币分配器的存储库可以决定它是否应该分配许多小硬币以及可能以哪种货币分配。硬币分配器可以验证机器中是否有足够的硬币。

不同的层有不同的验证。在类型化语言中，许多验证都是自动化的，例如你声明了一个 UUID，如果它实际上不是，那么它会在运行时出错。

您正在混合其他模式的抽象。存储库实现了来自用例的桥梁。来自用例的需求。在业务应用中，存储库中的公共 api 是它强制实现的所有桥接的总和。代码库是否选择在 API 层中实现所有桥接是一种权衡。

通常，Department 和 User 是直接从您对世界的心智模型映射出来的，但这并不是您设计软件时的最佳方式。

用例可能应该在 NewDepartment 和 NewDepartment 存储库等上运行。用户和部门甚至可能不存在于软件中。相反，存在 20 种不同的属性组合，它们会一起变化。你可以用复仇者或有意义的东西来称呼他们。应该尊重无处不在的语言，但是当它不适用时，“Thanos”可能是一个模块或概念的好名字。每个人都知道 Thanos 在您的项目中做了什么，它是清除数据或 w/e 的模块。或者，您可能将“欢迎”作为新部门等的概念。同样，尝试与无处不在的语言相协调，并尝试将自己从不会一起改变的事物的思维模式中解放出来。例如。客户状态和客户名称通常在完全不同的时间更改。

每个用例通常都有一个定义明确的桥，因此有一个专门的存储库。

权衡。不要将您的公共 API 耦合到数据库，例如不要返回数据库元组。将元组转换为对象并不会改变这一事实，因此通常至少需要一次转换。当业务逻辑中有很多代码时，通常还会进行二次转换，以允许数据库更改。

如何解决干净的架构边界

解决方法

相关推荐