在我从事的 DDD 之后的应用程序中，我们倾向于有一个服务层，其中包含服务 + 存储库 + 存储库和服务的接口，它们都存在于同一个程序集中，而域模型将存在于不同的程序集中.感觉就像在这个大项目中所有不适合领域模型的东西都杂乱无章。
在遵循 DDD 原则和模式的应用程序中，您如何打包存储库及其实现的接口？打包 DDD 应用程序的不同逻辑部分（或一般打包）的最佳实践是什么？每个逻辑分区都应该存在于自己的程序集中吗？这还重要吗？
【问题讨论】：
标签： c# domain-driven-design ddd-repositories
我会看看洋葱架构。基本上所有领域服务的领域模型和接口都被认为是核心。层仅依赖于它们上方更靠近核心的层。它们的实际实现由基础设施处理。
看这里http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
最终，您的界面决定了您的应用程序。如何实现的逻辑是外部化的。因此，我希望您拥有包含域模型和域服务的程序集、前端（例如 MVC 等），然后是实现 NHibernate 之类的基础设施程序集以提供数据等。
您可以在链接文章的各个部分看到实现架构的各种示例。最简单的在这里https://bitbucket.org/jeffreypalermo/onion-architecture/get/1df2608bc383.zip
你可以在这里看到与它相关的问题https://stackoverflow.com/questions/tagged/onion-architecture
主要的好处是，最常发生变化的主要是基础设施问题。新的数据层技术、新的文件存储等。此外，您的核心域应该相当稳定，因为它没有实现任何只是通过合约（接口）定义它需要的东西。通过将实现问题放在一个位置，您可以最大限度地减少整个程序集所需的更改量。
【讨论】：
您可以在DDD book 中找到设计图层的指南。你基本上得到了：
服务分为 3 种：应用层服务、基础设施层服务和领域层服务，具体取决于服务的功能。至于存储库，它们的合约（接口）通常驻留在域中，而它们的具体实现则在基础设施层中。
关于组件，我建议每层至少一个。程序集和 dll 都是关于可重用性、关注点分离和解耦的——我是否能够选择该 dll 并将其丢弃以在另一个应用程序中重用它？我是否能够做到这一点，而无需拖累一堆不相关的功能，这些功能会给其他应用程序带来不必要的复杂性？只需更改依赖注入模块中的一行代码，我就能轻松地将我的 dll 替换为另一个 dll 吗？等等。
【讨论】：