领域驱动设计 - 存储库和聚合根

发布于 2024-08-09 07:04:25 字数 590 浏览 6 评论 0原文

我有一个包含论坛的域模型。

我有论坛、主题和帖子实体。

该论坛是一个独立的实体。即它不包含线程作为聚合的一部分。这是因为线程不属于特定论坛(您可以将线程移动到不同的论坛)。

我不知道是否应该将帖子建模为线程聚合的一部分。没有主题,帖子就不可能存在。删除线程,您必须删除帖子,这告诉我将帖子作为线程聚合的一部分。

唯一的事情是,在编辑帖子时也可以单独获取帖子。即通过 id 编辑帖子时。

因此,我认为拥有一个帖子存储库将有助于此目的,而不必获取线程,然后通过线程实体上的方法获取正确的帖子。

拥有单独的帖子存储库的唯一问题是,在添加帖子(即 addPost(Post))时,您需要确保线程 id 已分配给帖子实体。通过聚合,我想您只需在线程实体上使用 addPost 方法。

我应该考虑有界上下文吗?我可以有一个帖子实体和存储库,并且还有一个也包含帖子实体的线程聚合吗?

如果我不使用线程/帖子聚合,当我删除线程时,我将如何处理帖子删除?我应该创建一个在线程存储库上调用deleteThread(Thread) 并在帖子存储库上调用deletePostsByThreadId(id) 的服务吗?

这里的 DDD 方式是什么?

I have a domain model that contains a forum.

I have forum, thread and post entities.

The forum is a standalone entity. Ie it does not contain thread as part of an aggregate. This is because threads are not owned by a particular forum (you can move a thread to a different forum).

I don't know if I should model posts as part of a thread aggregate. Posts can't exist without a thread. Delete a thread and you must delete the posts which tells me to make posts part of the thread aggregate.

The only thing is that posts also can be fetched standalone when editing them. Ie when editing a post by it's id.

So I think having a post repository would be good for this purpose, rather than having to fetch the thread, and then fetch the right post via a method on the thread entity.

The only thing with having a separate post repository is that when adding posts, ie addPost(Post), you need to make sure that the thread id has been assigned to the post entity. With an aggregate I guess you would just have the addPost method on the thread entity.

Should I be thinking of bounded contexts? Could I have a post entity and repository, and also have a thread aggregate that also includes post entities?

If I did not go with the thread/post aggregate, how would I handle post deletion when I delete a thread? Should I create a service that calls deleteThread(Thread) on the thread repository, and deletePostsByThreadId(id) on the post repository?

What is the DDD way here?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(1

み格子的夏天 2024-08-16 07:04:25

我想知道,对于你的情况,DDD 是否是一个好主意。我的意思是论坛本质上是面向数据的。也许您应该考虑一种最简单的方法,只使用经典的面向数据的技术来查询数据。 (即,LINQ、Hibernate、普通 SQL、实体框架或任何您想要的内容,具体取决于您的平台)

您的程序可能不需要域层,或者您最终会得到一个保存数据的类 ForumDTO 和保存数据的 Forum业务逻辑,对于帖子或线程来说是一样的,对我来说这似乎是一种反模式。

你怎么认为 ?

更新

我建议您阅读 Eric Evans 的书,它提供了 DDD 非常适合的复杂领域的精彩示例。
读完这本书后,我非常热衷于应用我所学到的知识,但我发现在某些情况下面向数据的方法更合适。

对我来说,论坛几乎没有复杂的域逻辑,因此您最终将在数据层和域层之间建立 1<->1 映射,正如我所说,这意味着重复和开销。

查看您的域的描述,您的方法似乎是面向数据的。
例如,直观上论坛有线程,线程有帖子,您所描述的域并没有反映这一点,并且您似乎规范化了对象模型以适应您的数据库模式(将被规范化)。

Forum 似乎是聚合根的最佳类(它更直观)

如果您确实想使用 DDD 方法,您可以在实体中注入存储库,并为您的域对象提供有意义的名称作为 thread.GetLastPostOf(User user) ,取决于您的要求。

但当你说你应该有一个带有 GetPostById 方法的存储库时,我同意你的观点。

I'm wondering, if in your case DDD is a good idea. I mean forums are data oriented by nature. Maybe should you consider a simplest approach and just use classic data oriented technologies to query your data. (ie, LINQ, Hibernate, plain SQL, entity framework or whatever you want depending on your plateform)

You program maybe doesn't need a domain layer, or you'll end up with a class ForumDTO which hold data, and Forum which hold business logic, same things for post or thread, to me it seems an anti-pattern.

What do you think ?

Update

I recommend you reading the book from Eric Evans, it has great examples of complex domain where DDD fits really well.
After reading this book I was vey enthusiastic to apply what I've learnt, but I've seen that is some case data oriented approach is more appropriate.

To me, there is almost no complex domain logic for a Forum, so you'll endup having a 1<->1 mapping between your data layer and domain layer, it means duplication and overhead as I said.

Seeing the description of your domain, your approach seems data oriented.
For example, intuitively a forum HAS threads and threads HAS posts, the domain as you describe it doesn't reflect that, and you seem to normalize your object model to fit your database schema (which will be normalized).

Forum seems the best class to be the Root of the aggregate (it's the more intuitive)

If you really want to use DDD approach, you can inject repositories in your entities, and give your domain object meaningfull name as thread.GetLastPostOf(User user), depending on your requirements.

But I agree with you when you say that you should have a repository with a method GetPostById.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文