在目录结构中明确上下文

Question

我正在寻找有关应用程序特定目录结构的反馈。我意识到这不遵循经典的堆栈溢出格式，其中有“正确答案”之类的东西，尽管它认为它很有趣。为了提供有意义的反馈，首先需要了解一些上下文，所以请多多包涵。

--

我和我的两个同事创建了一个使用Clean Architecture 的应用程序。对路由的 HTTP 请求被转换为请求模型，该模型被交给用例，然后生成一个响应模型，该响应模型被交给演示者。

代码完全开源，可以在on GitHub找到。我们还有some docs 描述了主要目录的内容。

我们正在考虑重新组织我们的代码，并希望就我们迄今为止的想法获得反馈。此次重组的主要原因包括：

• 现在我们没有一个好地方来放置不属于我们域的东西，但以某种方式绑定到它。例如授权代码，它知道捐赠 ID（授权不是核心域的一部分，而捐赠 ID 是）。

• 将有凝聚力的事物组合在一起非常好。我们的捐赠代码是有凝聚力的，我们的会员申请代码是凝聚力的，而两者并不相互依赖。这与领域驱动设计中的限界上下文概念密切相关。目前这些上下文在我们的代码中并不显式可见，因此很容易使它们相互依赖，尤其是当您不熟悉该领域时。

这些是我们迄今为止确定的上下文。这是一个初步列表，只是为了给你一个想法，而不是我想要反馈的部分。

• 捐赠
• 会员
• 表单支持内容（验证电子邮件、生成 IBAN 等）

我想要反馈的部分是我们考虑切换到的目录结构：

src/
    Context_1/
        DataAccess/
        Domain/
            Model/
            Repositories/
        UseCases/
        Validation/
        Presentation/
        Authorization/
    Context_2/
    Factories/
    Infrastructure/

tests/
    Context_1/
        Unit/
        Integration/
        EdgeToEdge/
        System/
        TestDoubles/
    Context_2/

直接在上下文中的Authorization/ 文件夹将为我们目前在基础设施中奇怪放置的授权代码提供一个主页。其他不属于我们域的代码，但绑定到它，可以直接进入上下文文件夹，如果其中有一组内聚/相关的东西，例如授权，则可以获取自己的文件夹。

我很高兴为您提供提供有用反馈所需的其他信息。

Answer 1

现在我们没有一个好地方来放置不属于我们域的东西，但以某种方式绑定到它。

目前这些上下文在我们的代码中并不显式可见，因此很容易使它们相互依赖，尤其是当您不熟悉该领域时。

解决这个问题有技术和非技术两种方法：

• 您可以通过类库强制执行更严格的分离。如果您必须导入 dll / 引用另一个项目，则更明显的是，您正在依赖某些东西。它还可以防止循环依赖。
• 代码审查/纪律是一种非技术性的处理方式。

我一直在将Hexagonal Architecture 与 DDD 一起使用，其中域位于中间。诸如存储库之类的其他问题由接口表示。然后，您的适配器会引用域，但绝不会在另一个方向上。因此，您的域中可能有一个 IRepository，但您的 WhatDatabaseRepository 位于它自己的项目中。然后，应用程序服务/命令处理程序负责协调您的用例并加载适配器。这也是您应用授权等跨领域关注点的地方。

我建议观看 Greg Young 的视频（尝试 this one）并阅读 Vaughn Vernon's IDDD，因为它涉及如何构建应用程序和处理像您这样的问题。 （抱歉，我的回答基本上是看一个 6 小时的视频并阅读一本 600 多页的书，但它们都确实帮助我澄清了 DDD 的一些更“笨拙”的方面）

例如，见https://github.com/gregoryyoung/m-r/blob/master/SimpleCQRS/CommandHandlers.cs