问题标签 [hexagonal-architecture]

上周我发现自己不得不开始考虑如何重构一个只包含单元测试的旧应用程序。我的第一个想法是使用 Cucumber 添加一些组件测试场景，以熟悉业务逻辑并确保我的更改不会破坏任何内容。但那时我与我工作的公司的一位架构师进行了交谈，这让我想知道这是否值得，以及我必须实际测试的代码到底是什么。

此应用程序有许多不同类型的端点：要调用和调用的其余端点、Oracle 存储过程和 JMS 主题和队列。它部署在 Tomcat 服务器的 war 文件中，到代理的连接工厂和到数据库的数据源在服务器中配置并使用 JNDI 获取。

我的第一个想法是在嵌入式 Jetty 中加载整个应用程序，指向真正的 web.xml，以便加载所有内容，就像从生产环境加载一样，然后模拟连接工厂和数据源。通过这样做，将测试部署应用程序的基础设施的所有连接逻辑。考虑到六边形架构，考虑到这些只是逻辑应该只是将接收到的数据转换为应用程序数据的端口，这似乎太过分了。这不应该只是单元测试吗？

我的下一个想法是在我的测试中模拟存储过程并在没有任何 Web 服务器的情况下加载 Spring XML，这使得模拟类更容易。为此，我将使用 Spring MockMvc 等库作为其余端点，将 Mockrunner 用于 JMS。但同样，这种方法仍然会测试一些适配器并使测试复杂化，因为测试的结果将是 XML 和 JSON 有效负载。在此应用程序中完成的转换非常繁重，其中相同的消息类型可能包含不同版本的类（每个消息可能包含许多实现多个接口的复杂对象）。

所以现在我在想，也许最好的方法是创建从入口点到应用程序的测试，从适配器调用的服务，并验证负责向代理发送消息或调用其他 REST 的服务实际上调用了端点。然后只需确保对端点进行适当的单元测试，并通过提供一些在真实环境中执行的冒烟测试来验证部署后一切正常。这将测试连接逻辑，并且将单独测试业务逻辑，而不关心是否添加了新适配器或删除了适配器。

这种方法正确吗？我会在不以这种方式测试的情况下留下一些东西吗？还是还是太多了，我应该相信单元测试？

谢谢。

我们正在设计一个具有干净/六边形架构范例的应用程序，但我们是这方面的新手。所以我们有一些问题。

场景是：

• 我们有一个外部 SOAP 服务，它给我们一些“实体”信息和相关的“文档”
• 对于每个实体，应用程序必须：
  • 将所有实体文档存储在 CMS 上（内容和一些实体属性）
  • 使用存储的文档参考将实体存储在 DDBB 上

让我们看看我们在类似 java 的方法上的初始解决方案：

实体和文件

领域层的 FRepositori 抽象

领域层的 DocumentRepositori 抽象

SOAP 服务在应用层的 ExternalService 抽象

应用层的用例实现

问题

1. 关于 ExternalService，用 Entity 和 Document 定义其抽象是正确的，还是必须返回一些 UseCase 实现将转换为实体的 ValueObject？
2. 关于 Document，我们是否必须将其设计为聚合根并从 Entity 中消除 Document 对象引用？

我正在学习 DDD 和 Hexagonal 架构，我想我已经掌握了基础知识。但是，我不确定如何解决一件事：我如何向用户显示数据？

因此，例如，我有一个简单的域，其中包含一个具有某些功能的 Worker 实体（某些方法会导致实体发生更改）和一个 WorkerRepository，以便我可以持久化 Worker。我得到了一个应用层，其中包含一些命令和命令总线来操作域（例如创建 Worker 并更新他们的工作时间，持久化更改），以及一个具有 WorkerRepository 和 GUI 应用程序实现的基础设施层。

在这个应用程序中，我想向所有工作人员展示他们的一些数据，并准备修改它们。如何显示数据？

1. 我可以给它一个 WorkerRepository 的实现的参考。我认为这不是一个好的解决方案，因为这样我可以在存储库中插入新的工人而跳过命令总线。我希望所有更改都通过命令总线。
2. 好的，我将 WorkerRepository 拆分为 WorkerQueryRepository 和 WorkerCommandRepository（根据 CQRS），并且只提供对 WorkerQueryRepository 的引用。这仍然不是一个好的解决方案，因为 repo 会返回具有更改它们的方法的 Worker 实体，这些更改将如何持久化？
3. 我应该创建两种类型的存储库吗？一种用于域和应用层，另一种仅用于向外界提供数据。第二个不会返回成熟的 Worker 实体，只有 WorkerDTO 只包含 GUI 需要的数据。这样，GUI 就没有其他方法可以改变 Workers，只能通过命令总线。

第三种方法是正确的方法吗？还是我错误地强迫更改必须通过命令总线？

我们正在为一个全新的domain model（和Bounded Context）“ Appointment”创建一个新的应用程序。我们选择为我们的新域结合CQS（Hexagonal Architecture使用端口和适配器）。

我们的包结构主要是这样的：

我的问题：

1. 这个包结构是否适合我们想要实现的目标？

2. 我们希望通过该AppointmentScheduleFacade接口查看与其他域之间的每一次通信。跨域通信以普通方法调用（没有 RPC 或 REST）的形式存在，因为它们不是分布式的。

   门面主要代表：

   • AppointmentScheduleApplicationService.java用于模型修改
   • AppointmentScheduleQueryService.java用于将数据传递到其他域。

这个设置好吗？或者其他域是否应该直接与Applicationand对应QueryService？

我试图通过一个例子来理解六边形架构Repository。在这个设置中，我有以下几层：框架（基础设施）-> 应用程序-> 域。

我User在域部分，假设我想User通过DuplicateUsernameValidator. 为了获得这些信息，我需要从某个地方获得这些信息。我UserRepository在领域层又增加了一个接口，这样就可以在上面的层解决了。

这对我来说是棘手的部分。我想实现 的逻辑UserRepository，但对我来说，在应用层实现它没有意义，因为持久性上下文在基础设施层（例如JdbcUserRepository或JpaUserRepository）。但是如果我正确理解了六边形结构，我就不能UserRepository直接在我的基础设施层中实现接口，因为基础设施层不应该知道域层。

我错过了什么？

我按照六边形架构编写系统。

我在 UseCase 中有异步命令和同步查询对象。

我的 src 文件夹如下所示：

我的问题是：我可以/应该使用什么来通过构造函数中的命令发送数据UseCase\Command\CreateTask\CreateTaskCommand

• \Entity\Task
• 创建UseCase\Command\CreateTask\Request\Task将包含所有需要的数据
• 只有字符串/整数/浮点数

这是显示问题的简单示例。

现在我正在使用域中的对象（Entiti\Task等）在实际情况下，我有UseCase\Command\CreateProcess这个需要

• 用户界面
• 实例[id，名称]
• 来源[node_id，node_name，leaf_id，leaf_name]
• Resource[id,name,type 等普通类型 Person[name,lastname]]

通过遵循 DDD，Process 是我的聚合。所有实体仅因构造 Process(Node,Leaf,Resource,Person) 而存在。然后我不想要单独的方式来创建其他实体，因为这种方式适用于我的业务逻辑。

由于这个问题，问题是：我应该选择什么？打破一些规则？

问题：

• 将命令与域内部的对象绑定，将更高层更多地绑定到核心。核心的任何变化，都会与所有层发生连锁反应
• 创建Request\*让我有很多课程，但使用命令的方式清晰，还有更多的工作 - unitTest 等。
• 仅使用标准类型（int、string 等）将使 __counstruct 具有 20 个参数。我不想要多级数组，因为不会清楚使用这个命令。

感谢帮助。

我开始使用 dto（数据传输对象），我对构建 API 系统架构的最佳方式有些怀疑。

想象一个域实体“A”，与“B”、“C”和“D”有关系。我们有一个服务“S”，它返回一个包含所有“A”的 json 列表。在该服务中创建“ADTO”是否正确，填写“BDTO's”、“CDTO's”和“DDTO's”？如果我们有另一个服务“S2”，我们需要返回一组特定的“B's”，那么我们需要创建另一个“B2DTO's”树与“C2DTOS's”，“D2DTO's”......？这是正确的方法吗？

我看到这样，我们将拥有一个庞大而复杂的 DTO 树，每个用例都有一个特定的 DTO。

编辑：

我忘记了汇编程序部分。是否需要为每个 DTO 实现不同的汇编程序？例如，对于实体 A，我们有两个 DTO。我可以使用相同的汇编器还是更好地使用 A1Assembler 和 A2Assembler？

在我们的项目中，我们使用 eclipse hibernate 插件生成的类进行持久化。生成的类具有以下结构。

我的问题是，如果我们使用映射文件中使用的 POJO 类作为最内层的实体，是否会违反 Uncle Bobs 的清洁架构。

在这种情况下，特定于休眠的 DAO 类将属于最外层，而 UseCases 层将通过提供要实现的接口与该层进行通信。

我正在使用 Specflow (C# cucumber) 使用 BDD 方法开发一个六边形应用程序。

我想实现自动化场景系统测试，运行核心并在内六边形的端口而不是生产适配器上注入测试双。

我也在使用组合根模式，这意味着核心依赖关系是在核心之外解决的：这对我来说已经很臭了（解决核心对注入适配器的外六边形的依赖关系是正确的，但是呢？核心的内部依赖关系？）。

通常测试类以它们的方式解决依赖关系，注入测试替身，但现在它们也必须能够组装核心。所以现在我们在解决核心的依赖关系方面没有一个事实，因为测试必须复制组合根，如果生产组合根替换核心的内部服务修改和破坏其行为，自动化测试仍然是绿色的，导致测试组合根仍然注入服务的旧实现。

这个问题的正确解决方案是什么？谢谢

我想沿着类似于我在问题末尾添加的“圆形轨迹”的六边形轨迹移动星形标记。谢谢。

这是我为创建同心六边形而编写的源代码，但我不知道如何移动穿过同心六边形的星形标记，我为圆轨迹编写了类似的模拟代码，但我做不到为六边形。

圆轨迹：