C# design-patterns architecture domain-driven-design

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

发布于 2024-10-26 07:17:51 字数 567 浏览 1 评论 0原文

我一直在阅读这本关于 DDD 的电子书，它说只有高度复杂的系统适合 DDD 架构。这让我重新思考我的决定，即更多地转向 DDD 作为我的架构。

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

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

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

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

如果不是DDD，那又是什么？仍在努力寻找好的方向。由于我仍在学习中，所以即使我不是一个完全的专家，它也需要快速、轻松地开始。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

一笔一画续写前缘 2024-11-02 07:17:51

DDD 不是一种架构。

它是一种设计哲学，你不能只是将所有 FooDAO 重命名为 FooRepositiories，添加一个反腐败层并称之为 DDD。

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

有一句名言：

“计算机科学中只有两个难题：缓存失效和命名。” — 菲尔·卡尔顿

而 DDD 确实有解决这些问题的模式。它提供了普遍存在的语言作为解决命名问题的模式，并且提供了经常被误解的模式集合：存储库、聚合、实体和值对象来解决模型一致性问题（我将把缓存失效归入其中，这里不再进一步介绍）。

但我想说最重要的是它增加了一个关键的第三项（不是 1 个问题）：

东西放在哪里

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

例如，在我的公司，我们与职位、求职者和招聘人员合作。求职者的世界与招聘人员的世界非常不同，他们对工作的看法也不同。举个例子，在招聘人员的世界（上下文）中，他们可以发布一份工作并说

我希望在纽约、奥斯汀和旧金山提供这份工作。

用面向对象的话说：一项工作有一个或多个位置。

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

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

DDD 的答案是两者兼而有之。如果您处于求职者的背景下，则一份工作只有一个地点，而如果您是该背景下的招聘人员，则一份工作可以有多个地点。

求职者上下文与招聘者上下文完全分开，它们不必不一定共享相同的模型。即使最终所有作业最终都在同一个数据库中（可能是另一个上下文本身），在上下文之间共享模型也可以使模型成为万事通，但一无所知。

现在这个例子非常具体地针对招聘和求职领域。它与ADO或MVC或ASP的实体框架无关。 DDD 与框架无关。

声称框架 A 或 B 使您的架构 DDD 是 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 需要认真地致力于审视和挑战您的设计，每天询问“这个模型是否使这种情况下的问题尽可能简单？”

但是，将什么表示框架（MVC 或无 MVC）和持久性框架（实体框架？）的战术和实际问题与业务领域建模任务分开。如果您想立即开始，请考虑您的应用程序中有哪些上下文。要问的一些问题：

应用程序的多个区域是否使用相同的基本数据解决不同的问题？
有多少个团队在开发该应用程序？
它们如何相互融合？

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

我鼓励您访问ddd 网站了解更多信息。 qcon 上也有一些很棒的 eric evans 视频。您可能还想阅读 Eric Evans 的书《领域驱动设计》，他有更多示例。

DDD is not an architecture.

It's a philosophy of design, you cannot just rename all your FooDAO's to FooRepositiories, throw in an Anti-Corruption Layer and call it DDD.

It stands for Domain Driven Design. It puts a focus on the models that you use to solve problems in your specific domain. What Eric Evans is suggesting is that if your site is simply a form to join a mailing list there's no reason to spend days in front of whiteboard playing with models. It's my opinion if there's only a single context in your domain you don't need DDD. More on that in a bit.

There's a famous quote:

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

And DDD does have patterns to address these. It offers ubitiquous language as pattern to tackle naming, and it offers the oft misunderstood collection of patterns: Repository, Aggregate, Entity, and Value Object to tackle model consistency (which I will lump cache invalidation into and won't cover further here).

But I would say most importantly it adds a critical 3rd item (not off by 1 problems):

Where to put stuff

Where to put code and logic. For me, the most fundamental concept in DDD is that of context. Not all problems are best served by the same model, and knowing where one context ends and another begins is a critical first step in DDD.

For instance, at my company we work with Jobs, Jobseekers and Recruiters. The world of a jobseeker is very different from the world of a recruiter and they both look at a Job differently. As an example, In the world (context) of Recruiters they can post a job and say

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

In OO speak: One Job has one or many Locations.

In the world of the jobseeker a job in LA is not the same job as a job in Boston. Nevermind if they are the same position at the same company. The difference in physical location is meaningful to the the jobseeker. While the recruiter wants to manage all Widget Manager jobs from a single place even if they are spread out around the country, a Jobseeker in New York does not care if the same position is also available in Seattle.

So the question is? How many Locations should a Job have? One or Many?

The DDD answer is both. If you're in the context of jobseeker then a job has only one location, and if you're a recruiter in that context a job can have many locations.

The Jobseeker context is wholly separate from the Recruiter Context and they should not necessarily share the same model. Even if in the end of the day all the jobs end up in the same DB (another context itself perhaps), sharing models between contexts can make a model a jack of all trades and master of none.

Now this example is very specific to the Domain of recruitment and jobseeking. It has nothing to do with Entity Framework of ADO or MVC or ASP. DDD is framework agnostic.

And it is DDD heresy to claim that framework A or B makes your architecture DDD. The whole point of DDD is that a model should serve the needs of a specific Context within a particular Domain. Frameworks can only support that and make it possible, they cannot do:

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

To specifically address the question, "To DDD? Or not to DDD?" The good news is you don't have to decide at the onset, "This is going to be a DDD project!" DDD requires no toolset other than the willingness to think hard about the problems you're trying to solve and ask is my code helping or hurting me?

The bad news is DDD requires a serious commitment to look at and challenge your design, asking every day "Is this model making the problems in this context as easy as possible?"

But separate the somewhat tactical and practical concerns of what presentation framework (MVC or no MVC) and persistence framework (Entity Framework?) from the task of modeling your business domain. If you want to start now, think about what contexts are in your app. Some questions to ask:

Are multiple areas of the application solving different problems with the same basic data?
How many teams work on the app?
How do they integrate with each other?

Mapping these out is called Drawing a Context Map and it's an important first step to starting to do DDD.

I encourage you to checkout the ddd website for more. There's some good eric evans videos on qcon too. You may also want to read the Eric Evans' book Domain Driven Design, he has many more examples.

回复收藏 0 原文

只为一人 2024-11-02 07:17:51

我强烈考虑研究 MVC 并按照示例 NerdDinner 网站。如果您使用 Linq to SQL 或 ADO.NET 实体框架，您将获得域层免费以及 ORM。这会处理所有数据访问，并使查询和过滤域对象变得轻而易举。

干杯

回复收藏 0 原文

面如桃花 2024-11-02 07:17:51

我在洋葱架构方面取得了巨大的成功... http:// jeffreypalermo.com/blog/the-onion-architecture-part-1/ 您可以从 Code Camp Server 获取此架构的示例（使用 DDD、MVC、NHibernate、测试驱动开发）....http ://codecampserver.codeplex.com/

回复收藏 0 原文

~没有更多了~