我正在使用 MVC 框架创建一个 Web 应用程序。我想在控制器和域模型之间添加一个层，我认为它在 DDD 中称为应用层，以避免将特定于特定用例的逻辑放入域模型中。 控制器将仅与该层交互，该层将使用域模型编排操作。该层将保持尽可能薄，推动所有不是特定于域模型的用例的逻辑。 我将调用属于这一层的类 DomainCtrl。
登录场景示例： 型号：登录表单 域控制：AuthCtrl UI：用户界面控制器
1.ui控制器接收请求 2.创建AuthCtrl的实例 3.AuthCtrl 创建一个 LoginForm 的实例并用传递给 authCtrl 的请求数据填充它 4.LoginForm 执行登录 5.authCtrl 做其他特定于这种特定登录方式的事情 -> 向 ui 控制器返回错误
这是组织应用程序的好方法吗？
【问题讨论】：
标签： model-view-controller domain-driven-design layer application-layer
你的问题
这是构建应用程序的好方法吗
是一个非常重要的问题。简单的答案是是，但更正确的答案是视情况而定。
让我们从简单的答案开始。让您的主应用程序不知道 UI 通常是一个好主意。这意味着您可以轻松地从各个地方使用您的应用程序。在 DDD 中，这个外层通常称为应用层。它主要负责协调您的域、持久性和您可能依赖的其他资源之间的交互。这也使您可以将您的域放在中心，而不知道其他所有内容。如果实施得当，这将使您的域易于测试和维护。
现在答案的“取决于”部分。 DDD 并不是构建应用程序的唯一成功方法，在某些情况下，它可能比其他任何事情都更具障碍。你必须问问自己我的应用程序在做什么。是否有许多特定于域的规则？我是否只获取和存储基本数据等？在选择架构和技术之前，这些都是您需要回答的问题。
我仍然想说，选择 DDD 方法可能不会出错，因为它通常是一种很好的做事方式。
*注意：您的示例对我来说不是很清楚，但是您应该小心将 UI 概念溢出到您的域/应用程序中。登录表单在某种程度上完全是一个 UI 概念，就像 auth 一样。您可能可以让您的应用程序返回您的用户的详细信息，但 UI 层应决定是否允许用户继续。
【讨论】：
在高层次上，是
但这最终取决于您“如何”在逻辑上分离图层。在您的场景中，我没有看到任何应用层。
【讨论】：