3

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

--

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

该代码是完全开源的，可以在 GitHub 上找到。我们还有一些文档描述了主目录的内容。

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

  • 现在我们没有一个好地方来放置不属于我们域的东西，但以某种方式绑定到它。例如授权代码，它知道捐赠 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/文件夹将为我们当前在基础设施中奇怪放置的授权代码提供一个主页。其他不属于我们域的代码，但绑定到它，可以直接进入上下文文件夹，如果其中有一堆内聚/相关的东西，例如授权，则可以获取自己的文件夹。

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

4

1 回答 1

4

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

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

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

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

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

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

例如，请参阅https://github.com/gregoryyoung/mr/blob/master/SimpleCQRS/CommandHandlers.cs

于 2016-06-26T10:08:26.197 回答