namespaces - 在目录结构中明确上下文

Question

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

--

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

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

我们正在考虑重新组织我们的代码，并希望就我们目前所做的工作获得反馈。此次重组的主要原因包括:

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

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

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

• 捐赠
• 成员(member)资格
• 表单支持(验证电子邮件、生成 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/ 文件夹将为我们目前在基础设施中奇怪放置的授权代码提供一个家。其他代码不属于我们的领域，但绑定(bind)到它，可以直接进入上下文文件夹，如果其中有一堆内聚/相关的东西，比如授权，就可以得到它自己的文件夹。

我很乐意提供您提供有用反馈所需的额外信息。

Answer 1

Right now we do not have a nice place to put things that are not part of our domain, yet somehow bind to it.

Right now these contexts are not explicitly visible in our code, so it is easy to make them dependent on each other, especially when you are not familiar with the domain.

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

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

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

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

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