应用程序行为相关组件在哪些方面适合 DDD？
如果我使用 DDD 开发应用程序，基础设施和行为组件在哪里？例如，用户管理、用户特定配置、权限、应用程序菜单等。
这些组件实际上与我的域所满足的业务需求无关，但它们仍然是我的应用程序所需的元素。其中许多还需要坚持。
If I am developing an application using DDD, where do the infrastrucure and behavior components go? For example, user management, user specific configuration, permissions, application menuing, etc.
These components really have nothing to do with the business requirements being fullfilled by my domain, but they are still required elements of my application. Many of them also require persistance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在项目中将非域组件与域一起使用是很正常的 - 毕竟并非所有内容都是面向业务域的。它们的归属实际上取决于您如何构建解决方案。在大多数情况下，我倾向于遵循洋葱架构，所以我所有的逻辑由应用程序服务提供，无论它是面向域的还是非面向域的。
It's pretty normal to have non-domain components along with the domain in your project - after all not everything is business domain oriented. Where they belong actually depends on how you structure your solution. In most cases I tend to follow Onion Architecture, so all of my logic is provided by Application Services, regardless if it's domain or non-domain oriented.
如果您发现您的用例很少需要来自核心域的信息与特定于应用程序的信息相结合，那么您可以将其拆分到一个单独的数据库中。通过应用程序服务层访问此信息，因为该层应该满足您的应用程序需求。如果这包括用户配置文件持久性等，那就没问题了。
但您请记住，如果您遇到基础设施故障并且想要对某些事务日志或数据库备份进行回滚，您可能希望回滚所有持久数据。这样让这些域共享数据库就更容易了。优点和缺点 - 总是妥协...
如果我知道这个应用程序将与其环境进行少量交互，我会将其放入一个数据库中，并让应用程序服务层与客户端交互。
如果我知道会有多个应用程序/客户端，我可能会考虑拆分数据库，以便将 Webb 应用程序用户详细信息存储在单独的数据库中。很难说，因为我不了解所有要求。
/马格努斯
Well if you find that your usecases rarely demands information from your core domain joined with application specific, you can probably split that into a separate database. Access this information through Application Service layer, since this layer is suppose to serve your application needs. If that includes user profile persistence etc, that's fine.
But you remember that if you got infrastructural failure and you want to do a rollback with some transaction logs or database backups, you'd probably want all persisted data be roll-backed. So then it's easier to have these domains share a database. Pros and cons - always compromise...
If I know that this application would have minor interaction with it's environment, I would put this in one database and let the application service layer interact with clients.
If I know that there will be several applications/clients I may consider to split database so that Webb application user specifics are stored in separate database. Very hard to say, since I have no overview of all the requirements.
/Magnus