当前位置：文江博客话题详情

如何组织领域驱动设计项目？

发布于 2024-07-13 13:17:16 字数 738 浏览 11 评论 0原文

我已经开始学习 DDD，并想了解其他人如何组织他们的项目。

我首先围绕我的 AggregateRoots 进行组织：

MyApp.Domain（域模型的命名空间）

MyApp.Domain.Product
- 产品
- IProductService
- IProductRepository
- 等

MyApp.Domain.Comment
- 评论
- ICommentService
- ICommentRepository
- 等

MyApp.Infrastructure
- ...

MyApp.Repositories
- 产品存储库：IProductRepository
- 等等

我遇到的问题是我必须将我的域产品引用为 MyApp.Domain.Product.Product 或 Product.Product。我还与产品的 linq 数据模型发生冲突......我必须使用丑陋的代码行来区分两者，例如 MyApp.Domain.Product.Product 和 MyApp.Respoitories.Product。

我真的很想知道其他人如何组织他们的 DDD 解决方案...

我使用 Visual Studio 作为我的 IDE。

多谢。

原文

分享到QQ

分享到微博

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

发布评论

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

她如夕阳 2024-07-20 13:17:16

我尽量让事情变得非常简单，所以通常这样的事情对我有用：

Myapp.Domain - 所有特定于域的类共享这个命名空间

Myapp.Data - 从域中抽象数据库的薄层。

Myapp.Application - 所有“支持代码”、日志记录、共享实用程序代码、服务消费者等

Myapp.Web - Web UI

因此类将是例如：

Myapp.Domain.Sales.Order
Myapp.Domain.Sales.Customer
Myapp.Domain .Pricelist
Myapp.Data.OrderManager
Myapp.Data.CustomerManager
Myapp.Application.Utils
Myapp.Application.CacheTools

等等。

我在进行过程中试图牢记的想法是“域”名称空间捕获了实际的逻辑应用程序。因此，您可以与“领域专家”（将使用该应用程序的人）讨论什么。
如果我因为他们提到的某些内容而编写某些内容，那么它应该位于域名称空间中，并且每当我编写他们没有提到的内容（例如日志记录、跟踪错误等）时，它不应该位于域名称空间中。

因此，我也对创建过于复杂的对象层次结构持谨慎态度。理想情况下，非编码人员应该可以直观地理解领域模型的某种简化绘图。

为此，我通常不会一开始就详细考虑模式。我尝试尽可能简单地对域进行建模，遵循标准的面向对象设计指南。什么必须是一个对象？它们有何关系？

在我看来，DDD 是关于处理复杂的软件，但如果您的软件本身一开始就不是很复杂，那么您很容易就会陷入这样的情况：DDD 的做事方式增加了复杂性，而不是消除了复杂性。

一旦模型达到一定程度的复杂性，您将开始了解应如何组织某些事物，然后您将知道要使用哪些模式、哪些类是聚合等。

在我的示例中，Myapp.Domain.Sales.Order是一个聚合根，因为当它被实例化时，它可能包含其他对象，例如客户对象和订单行集合，并且您只能通过订单对象访问该特定订单的订单行。

但是，为了使事情简单，我不会有一个仅包含其他所有内容且没有其他目的的“主”对象，因此订单类本身将具有在应用程序中有用的值和属性。

因此，我将引用以下内容：

Myapp.Domain.Sales.Order.TotalCost

Myapp.Domain.Sales.Order.OrderDate

Myapp.Domain.Sales.Order.Customer.PreferredInvoiceMethod

Myapp.Domain.Sales.Order.Customer.Address.Zip

等。

I try to keep things very simple whenever I can, so usually something like this works for me:

Myapp.Domain - All domain specific classes share this namespace

Myapp.Data - Thin layer that abstracts the database from the domain.

Myapp.Application - All "support code", logging, shared utility code, service consumers etc

Myapp.Web - The web UI

So classes will be for example:

Myapp.Domain.Sales.Order
Myapp.Domain.Sales.Customer
Myapp.Domain.Pricelist
Myapp.Data.OrderManager
Myapp.Data.CustomerManager
Myapp.Application.Utils
Myapp.Application.CacheTools

Etc.

The idea I try to keep in mind as I go along is that the "domain" namespace is what captures the actual logic of the application. So what goes there is what you can talk to the "domain experts" (The dudes who will be using the application) about.
If I am coding something because of something that they have mentioned, it should be in the domain namespace, and whenever I code something that they have not mentioned (like logging, tracing errors etc) it should NOT be in the domain namespace.

Because of this I am also wary about making too complicated object hierarchies. Ideally a somewhat simplified drawing of the domain model should be intuitively understandable by non-coders.

To this end I don't normally start out by thinking about patterns in much detail. I try to model the domain as simple as I can get away with, following just standard object-oriented design guidelines. What needs to be an object? How are they related?

DDD in my mind is about handling complex software, but if your software is not itself very complex to begin with you could easily end up in a situation where the DDD way of doing things adds complexity rather than removes it.

Once you have a certain level of complexity in your model you will start to see how certain things should be organised, and then you will know which patterns to use, which classes are aggregates etc.

In my example, Myapp.Domain.Sales.Order would be an aggregate root in the sense that when it is instanced it will likely contain other objects, such as a customer object and collection of order lines, and you would only access the order lines for that particular order through the order object.

However, in order to keep things simple, I would not have a "master" object that only contains everything else and has no other purpose, so the order class will itself have values and properties that are useful in the application.

So I will reference things like:

Myapp.Domain.Sales.Order.TotalCost

Myapp.Domain.Sales.Order.OrderDate

Myapp.Domain.Sales.Order.Customer.PreferredInvoiceMethod

Myapp.Domain.Sales.Order.Customer.Address.Zip

etc.

回复收藏 0 原文