Architecture 干净的架构边界

我对清洁体系结构比较陌生，我对在后端spring项目中使用CA有一些疑问

应用程序是否必须（CA是一种良好的做法）模块化，或者它可以是文件夹中拆分的一个模块

关于业务逻辑，是否应该只在用例上

我可以在任何层中使用“验证器”吗？ 例如 是否可以在InputRequest对象上验证大小、可空、可选字段？或者在控制器本身调用PaginationValidator，例如？ 存储库中的验证在我有以下业务规则时检查字段是否应该更新：“如果字段为空，则不更新，否则更新它”。 如果我有一个用例调用网关，那么网关也可以调用验证器吗？或者验证必须在用例中进行？

存储库

存储库是网关吗？如果是，它适合哪一层？ 假设我在DB上有两个实体，Department和Employee。业务规则是：“要创建一个部门，我也必须创建其员工，而且只能通过部门”。 在这种情况下，我该怎么办？ 我应该创建两个存储库吗？由于我在创建部门时只能创建员工，我应该通过部门存储库从员工的存储库调用create（）？ 即使我在创建部门时只能创建员工，我是否应该有两个用例（一个用于创建部门，一个用于创建员工）？ 如果我有两个用例，我应该通过部门用例调用员工用例还是创建另一个用例来协调它们？ 我应该只创建一个用例并创建一个网关来协调存储库吗？ 还有其他选择吗？ 关于存储库，我可以通过存储库调用用例吗？这让我非常困惑，因为从理论上讲，用例和存储库将有接口，其实现可以在同一层上，但箭头将向前和向后移动，不是吗？

DTO

它可能有第二个构造函数需要“输入”，而这个构造函数会填充相应的字段吗？e、 g.有一个建造师需要一个部门请求的部门 如果我必须创建三层域，有什么规则吗？像部门请求、部门和部门实体？如果不是，一个实体只能有两个或一个对象吗？ 所有的转换都应该通过汇编程序/转换器吗？

我已经在网上搜索过了，但是所有这些信息似乎都太抽象了，有时甚至模棱两可，如果有人能给我举例说明，我将不胜感激！ 谢谢 应用程序是否必须模块化，或者可以是文件夹中拆分的一个模块

我可以模块化，但不能。模块化在java或C++等编译语言中有好处，因为你不能在模块之间引入循环。例如，如果在Java中，JARB依赖于JARB，则不能将依赖关系从JARB引入JARB，因为这将引入一个循环，然后在JARB构建之前无法构建JARB，反之亦然

根据您的需要，将其拆分为文件夹、包或名称空间（取决于您的语言命名方式）是有意义的。看看我对这个问题的回答

关于业务逻辑，它应该只在用例上吗

所有业务规则都应该放在用例层或下面，因为干净体系结构的目标是使这部分易于测试。应用程序特定的业务逻辑应该放在用例中，应用程序无关的规则应该放在实体中

关于输入，是在控制器上还是在域（请求）中

将特定于控制器的验证与业务验证分开。特定于控制器的应该放在控制器级别，特定于业务的应该放在用例和/或实体层

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

用例层应该抛出业务异常，比如

scheduledTimeLapsedException

。控制器层可以捕获此异常并决定执行什么操作，例如，rest服务可能返回HTTP状态代码和/或带有更详细描述的JSON，可能是国际化描述，具体取决于请求客户端的语言设置

存储库

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

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

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

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

我应该创建两个存储库吗？由于我在创建部门时只能创建员工，我应该通过部门存储库从员工的存储库调用create（）

您应该应用接口隔离原则并创建特定于用例的存储库接口。这个接口应该只定义用例需要的方法。因为业务规则是同时创建这两个，所以

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