Namespaces 使上下文在目录结构中显式

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

--

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

代码是完全开源的，可以找到。我们还描述了主目录是关于什么的

我们正在考虑重新组织我们的代码，并希望得到到目前为止我们提出的反馈意见。此次重组的主要原因包括：

• 现在，我们没有一个好的地方来放置不属于我们领域的东西，但却以某种方式绑定到它。例如，授权代码，它知道捐赠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/

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

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

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

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

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

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

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

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

---

例如，请参见

您是说授权不应该在用例中完成，而应该由调用特定用例的东西来完成吗？应用程序服务通常会实现一个用例。因此，如果您的用例是“捐赠”，您将有一个应用程序服务（或者更可能是一个命令处理程序）来处理这个问题。在这里面，你可以确保这个人被授权进行捐赠。是命令处理程序的一个示例。在这里，您还可以将执行授权的东西传递给构造函数。更好的方法是在命令处理程序类本身上使用decorator模式。在我引用的视频中看到这一点