问DDD基础设施服务

EN

坚持DDD定义，存储库不同于服务。存储库直接关联到一个实体，通常是一个聚合根。服务定义的行为并不真正属于您的域中的单个实体。您绝对可以在每一层中找到服务，尽管它们解决的问题类型因层而异，并且可能与DDD的概念性服务不同。

在概念级别上工作时，DDD存储库与DDD服务的不同之处在于它专门绑定到实体持久性。服务可以解决您可能遇到的任何域、应用程序或基础架构问题。

你会遇到与DDD到处都是的术语冲突。例如，DDD Repository与Martin Fowler的PoEAA一书中的Repository pattern不是一回事，尽管它可能采用这样的模式。这通常是许多人感到困惑的一个原因。

如果你总是把领域模型放在你所做的每件事的中心，这对DDD很有帮助。当涉及到对DDD应用进行分层时，我经常选择Jeffrey Palermo's Onion Architecture。看看这个。下载CodeCampServer，一个使用此架构的示例应用程序。我认为它非常适合DDD编程。

祝好运!

也许这将有助于看到一个潜在的项目结构。

可能的程序集或包结构：

Project.Domain

Project.Infrastructure.Data

Project.Infrastructure.Components

Project.Infrastructure.Services

可能的命名空间或文件夹结构：

Project.Domain

-n-模块

-n- Account

-f- Account.xx

-f- AccountRepository.xx

-f- Contact.xx

-n-营销

-f- RegionRepository.xx

-n-共享

-n-服务

Project.Infrastructure.Data (OR映射器)

-n-表

-n-视图

-n-步骤

-n-函数

Project.Infrastructure.Components (通用)

-n- Mail

-n-加密

-n- UI

Project.Infrastructure.Services (特种作战)

-f- DoingSomethingService1.xx

-f- DoingSomethingService2.xx

-f- DoingSomethingService3.xx

域实体和值类型不使用域服务。应用层使用域的服务。域存储库对象使用Infrastructure.Data对象返回域对象。

关于DDD的一个不幸的事情是“服务”这个词。它应该是“域服务”。将域视为实体和值对象，而服务是一种处理操作、操作和活动的方法。

至于存储库，它们只是一个外观，应该表现为您的域的集合。如果您正在使用ORM或编写自己的ORM，这是所有域对象都应该经历的，以便实现持久性，而不是直接使用这些服务。