c# - 领域驱动设计适合我的项目吗？

Question

我一直在阅读this ebook about DDD它说只有高度复杂的系统才适合 DDD 架构。这让我再次猜测我决定更多地转向 DDD 作为我的架构。

我正在将经典的 ASP 应用程序逐节转换为 .NET。它包括一个强大的产品分类方案和每天收到约 100-200 个订单的购物车，以及一个类似于 YouTube 的视频部分(视频和社交功能，如评分、评论等)。由于我已将其分块转换，因此我想将站点的每个区域视为单独的项目。

该站点不断获得新功能，并且需要易于维护和更新。

现在我只是使用一个基本的自制 ADO.NET DAL，其中 BLL 和 DTO 充当公共(public)层。

对于这个项目，使用与 DDD 不同的架构会更好吗？我是架构新手，想使用某种模式作为指导，我可以在整个转换过程中遵循它，以避免可怕的意大利面条式反模式。

如果不是DDD，那又是什么？仍在努力寻找一个好的方向。由于我仍在学习，因此无需成为完整的专家就可以快速轻松地开始。

Answer 1

DDD 不是一种架构。

这是一种设计哲学，您不能只是将所有 FooDAO 重命名为 FooRepositiories，放入反腐败层并将其称为 DDD。

它代表领域驱动设计。它侧重于您用来解决特定领域问题的模型。埃里克·埃文斯 (Eric Evans) 的建议是，如果您的网站只是加入邮件列表的一种形式，则没有理由在白板前花几天时间玩模型。我的观点是，如果您的域中只有一个上下文，则不需要 DDD。稍后会详细介绍。

有一句名言:

“There are only two hard problems in Computer Science: cache invalidation and naming things.” — Phil Karlton

DDD 确实有解决这些问题的模式。它提供了无处不在的语言作为模式来解决命名问题，并且它提供了经常被误解的模式集合:存储库、聚合、实体和值对象来解决模型一致性问题(我将缓存失效归为一类，这里不再赘述)。

但我会说最重要的是它增加了一个关键的第三项(不是 1 个问题):

Where to put stuff

在哪里放置代码和逻辑。对我来说， DDD 中最基本的概念是上下文 .并非所有问题都可以通过同一个模型得到最佳解决方案，了解一个上下文在哪里结束，另一个从哪里开始是 DDD 中关键的第一步。

例如，在我的公司，我们与 Jobs、Jobseekers 和 Recruiters 合作。求职者的世界与招聘人员的世界大不相同，他们对工作的看法也不同。例如，在招聘人员的世界(上下文)中，他们可以发布工作并说

I want to make this job available in New York, Austin, and San Fran.

用 OO 来说:一项工作有一个或多个位置。

在求职者的世界里，洛杉矶的工作与波士顿的工作不同。没关系，如果他们是同一家公司的同一职位。 物理位置的差异对求职者来说意义重大 .虽然招聘人员希望在一个地方管理所有 Widget Manager 工作，即使它们分布在全国各地，但纽约的求职者并不关心西雅图是否也有相同的职位。

那么问题是？一个工作应该有多少个位置？一个还是多个？

DDD 的答案是两者兼而有之。如果您在 的上下文中求职者那么一份工作只有一个地点，如果你是 招聘人员在这种情况下，一个工作可以有多个位置。

Jobseeker 上下文与 Recruiter 上下文完全分开，它们应该 不是 必然共享相同的模型。即使在一天结束时所有的作业最终都在同一个数据库中(可能是另一个上下文本身)，在上下文之间共享模型可以使模型成为所有行业的杰作而一事无成。

现在这个例子非常特定于招聘和求职领域。它与 ADO 或 MVC 或 ASP 的 Entity Framework 无关。 DDD 与框架无关。

和 DDD 异端声称框架 A 或 B 使您的架构 DDD . DDD 的全部意义在于，模型应该满足特定领域内特定上下文的需求。框架只能支持并使其成为可能，它们不能:

$ dddonrails new MyDDDApplication
$ dddonrails generate context ContextA
$ dddonrails generate context ContextB
$ dddonrails generate model Widget ContextA
$ dddonrails generate model Widget ContextB
$ dddonrails start

专门解决这个问题，“DDD？还是不DDD？” 好消息是您不必一开始就决定 , “这将是一个 DDD 项目!”除了愿意认真思考您试图解决的问题并询问我的代码是帮助还是伤害我之外，DDD 不需要任何工具集？

坏消息是 DDD 需要认真的 promise 来审视和挑战你的设计，每天都要问“这个模型是否使这种情况下的问题尽可能简单？”

但是，将表示框架(MVC 或无 MVC)和持久性框架( Entity Framework ？)的一些战术和实际问题与业务域建模任务分开。如果您想立即开始，请考虑您的应用程序中的上下文。一些问题要问:

应用程序的多个领域是否使用相同的基本数据解决不同的问题？

有多少团队在开发应用程序？

它们是如何相互融合的？

将这些映射出来称为 绘制上下文 map 这是开始做 DDD 的重要第一步。

我鼓励您结帐 the ddd website更多。 qcon 上也有一些很好的 eric evans 视频。您可能还想阅读 Eric Evans 的书域驱动设计，他有更多的例子。