domain-driven-design - 如何组织领域驱动的设计项目？

Question

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

我从围绕AggregateRoots开始组织:

MyApp.Domain(域模型的命名空间)

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

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

MyApp.Infrastructure
-...

MyApp。存储库
-ProductRepository:IProductRepository
-等

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

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

我使用Visual Studio作为我的IDE。

非常感谢。

Answer 1

我会尽可能使事情保持简单，因此通常这样的事情对我来说很有效:

Myapp.Domain-所有特定于域的类共享此 namespace

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

等等。

我尝试时要牢记的想法是，“域” namespace 是捕获应用程序实际逻辑的地方。因此，您可以与“ Realm 专家”(将使用该应用程序的家伙)谈论什么。
如果我因某人提及的内容进行编码，则应将其放在域 namespace 中，并且每当我对他们未提及的内容进行编码(如日志记录，跟踪错误等)时，均不应将其包含在域 namespace 中。

因此，我也对制作过于复杂的对象层次结构持谨慎态度。理想情况下，非编码者应该可以直观地理解领域模型(Domain Model)的简化图。

为此，我通常不会首先详细考虑模式。我尝试遵循标准的面向对象设计准则，尽可能简单地对域进行建模。什么是对象？它们有什么关系？

我认为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

等等