实施域驱动设计

Question

是否有人使用域驱动设计技术？我最近阅读了埃里克埃文斯同名书（其中大部分是！），并且有兴趣听到任何人在项目中实现了全部/部分内容（特别是在C＃/ C++中）

我已经把这个问题开放式的，我想看到的许多意见越好，但我有特别的几个问题：

1 - 如果值类型是真正的“价值型”如果语言支持的话？例如在C＃

2-一个结构是否有在C＃，使更清晰的语言和该模型之间的关联的任何特征（例如，这是一个实体，这是一个聚集体等）

Answer 1

是的！我在我的项目中使用DDD（但是I'm biased！）

请记住，域驱动设计提供准则，而不是严格的答案。只有在试验之后，您才会明白哪些方面适用于您的特定项目。

到你的问题：

1 - 你可以使用结构 - 但有可能是技术的限制阻止你使用它们。例如，您可能有引用数千个值对象的实体碰巧具有相同的值。在这种情况下，它可能是更好地使用轻量级对象保持内存使用下来。

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

我已经创建了一个专门关注DDD的[免费.NET库] [2]，它可能会从中找到想法/灵感。 [3] （项目已死）

我真的很感兴趣，但：DDD的哪些方面你认为会对你有好处吗？ “领域驱动”方面，还是实施方面？

Answer 2

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

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

我建议在明年读：斯科特·安布勒的“建设目标应用程序的工作”。

Answer 3

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

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

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

我会去与命名约定，例如， “CustomerEntity”， “OrderAggregate” 等

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

Answer 4

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

不要混淆“Value Object”的DDD概念和“Value Type”的CLR概念（C＃中的结构）之间的混淆。前者与设计有关，而后者是较低层次的实现考虑因素，与内存管理相比，其实更重要。

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

当解决实体与值，是的。我们发现在C＃中使用readonly对于在DDD中实现值对象非常有用。我们在Pluralsight中以很大的方式拥抱DDD，并不时在Pluralsight博客上关于它的博客。事实上，我已经安排了两篇关于只读和DDD的博客文章，以便本周晚些时候出版。

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