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