实施领域驱动设计

Question

有人使用Domain Driven Design的技术吗？ 我最近读过Eric Evans的同名书（好吧，大部分都是这样！）并且有兴趣听一下在项目中实现全部/部分内容的人（特别是在C＃/ C ++中）

我一直把这个问题保持开放，因为我希望看到尽可能多的评论，但我特别提出几个问题：

1 - 如果语言支持，值类型应该是真正的“价值类型”吗？ 例如C＃中的结构

2- C＃中是否有任何特性使语言与模型之间的关联更加清晰（例如，这是一个实体，这是一个聚合等）

Answer 1

是! 我在我的项目中使用DDD（但我有偏见 ！）

请记住，域驱动设计提供了指导原则 ，而不是严格的答案。 只有在经过实验之后，您才能了解哪些方面适用于您的特定项目。

在你的问题上：

1 - 您可以使用结构 - 但可能存在阻止您使用结构的技术限制 。 例如，您可能有实体引用了数千个碰巧具有相同值的值对象。 在这种情况下，最好使用flyweight对象来降低内存使用率 。

2 - 我建议使用接口 （例如IEntity ， IValueObject ， IAggregateRoot ， ISpecification ）。 泛型和LINQ可以帮助解决技术问题，但从设计角度来看，它们的帮助较少。

我创建了一个[免费的.NET库] [2]专门关注DDD，它可能会从中找到想法/灵感。 [在这里阅读更多相关信息。] [3] （项目已经死亡）

我真的很感兴趣： 您认为DDD的哪些方面对您有益？ “领域驱动”方面，还是实施方面？

Answer 2

1：取决于。 C＃中的值类型用于原子pimitives（int，byte等）。 如果你有类似的东西 - 这是有道理的。 如果您的值类型较大，则不。

2：否。通常，这不是语言功能。

我建议下一篇：Scott Ambler的“构建对象应用程序”。

Answer 3

1 - 如果语言支持，值类型应该是真正的“价值类型”吗？

我认为答案取决于应用程序中的使用情况和其他因素，但您可能正在寻找的模式是“数据传输对象”，它具有属性，getter和setter，但没有别的。 它可以是结构或对象，对象可能会简化内存管理问题，尤其是在装箱方面。

2- C＃中是否有任何特性使语言与模型之间的关联更加清晰（例如，这是一个实体，这是一个聚合等）

我会使用命名约定，例如“CustomerEntity”，“OrderAggregate”等。

好问题; 我期待看到回应。

Answer 4

1 - 如果语言支持，值类型应该是真正的“价值类型”吗？ 例如C＃中的结构

不要混淆“值对象”的DDD概念和“值类型”的CLR概念（C＃中的结构）。 前者与设计有关，后者是较低级别的实现考虑因素，实际上与内存管理有关。

2 - C＃中是否有任何特性使语言和模型之间的关联更加清晰（例如，这是一个实体，这是一个聚合等）

在处理实体与价值观时，是的。 我们发现在C＃中使用readonly对于在DDD中实现Value Objects非常有帮助。 我们在Pluralsight上大力采用DDD，我不时在Pluralsight博客上发表这篇文章。 事实上，我已安排两篇关于readonly和DDD的博客文章将在本周晚些时候发布。

[1] http://blog.pluralsight.com/tag/ddd/