解决方案源代码组织指南（OO / DDD）

Question

我正在开始我的第一个商业项目（.NET），并且正在尝试遵循DDD原则。是否有任何指导方针或共同模式来讨论源代码和名称空间？

例如，您的域对象是否在命名空间MyProject.Domain或其他内容中？你会分开具体的实现和接口吗？在不同的命名空间？不同文件夹？不同的解决方案？

我知道很多这是主观的，并且取决于项目规模，但是在一个相对较小但可扩展的n层项目上开始的一些指示或建议将是有用的。

Answer 1

有许多正确的方法来组织DDD应用程序的解决方案，因此请接受实验。我几次改变了我的个人解决方案布局。我认为细节取决于您使用的技术，但整体组织保持不变。

• 每个有界背景下的一个解决方案
• 包含模型的一个域项目（实体，值对象，存储库接口等）
• One Domain.Persistence（或DataAccess）项目，包含NHibernate映射，存储库实现和特定于NHibernate的类型。如果你有一个拥有多个持久层的认真计划，你可以将它们命名为Domain.Persistence ..
• 包含应用程序层代码（服务）的一个应用程序项目
• 任意数量的UI或Windows服务项目

看看我的DDDSample.Net项目。它包含针对同一问题的DDD解决方案的许多变体。我刚刚描述了最典型的简单，但有更复杂的，特别是：

• 具有多个图层的模型
• CQRS系统
• 事件采购CQRS系统

希望有所帮助。

Answer 2

我也是新手，但这就是我所做的。

我们项目组织的根源是我们的公司名称，称之为公司。这些项目的布局如下：

• Company.Core有几个名称空间：

  .Data定义DAL的接口

  .Repository定义了我们的存储库的基本接口

• Company.Data是DAL的具体实现

• Company.Domain是域对象，其中定义了存储库接口

• Company.Repository是存储库的具体实现

• Company.Tests有许多名称空间：

  .Data测试DAL，.Data.Mock嘲笑它

  。存储库测试存储库，.Repository.Mock模拟它们

  .Domain使用模拟存储库测试域对象

所有这些都与AutoFac连接在一起