是否有人使用域驱动设计技术？我最近读过Eric Evans的同名书（好吧，大部分都是！），并且有兴趣听一下在项目中实现全部/部分内容的人（特别是在C＃/ C ++中）
我一直把这个问题保持开放，因为我希望看到尽可能多的评论，但我特别提出几个问题：
1 - 如果语言支持，值类型应该是真正的“价值类型”吗？例如C＃中的结构
2- C＃中是否有任何特性使语言和模型之间的关联更加清晰（例如，这是一个实体，这是一个聚合等）。
答案 0 :(得分：6)
是的！我在我的项目中使用DDD（但是I'm biased！）
请记住，域驱动设计提供指南，而不是严格的答案。只有在经过实验之后，您才能了解哪些方面适用于您的特定项目。
问题：
1 - 您可以使用结构 - 但可能存在阻止您使用结构的技术限制。例如，您可能有实体引用了数千个碰巧具有相同值的值对象。在这种情况下，最好使用 flyweight 对象来保持内存使用率。
2 - 我建议使用接口（例如 IEntity ， IValueObject ， IAggregateRoot ， ISpecification ）。泛型和LINQ可以帮助解决技术问题，但从设计的角度来看，它们的帮助不大。
我创建了一个[免费的.NET库] [2]专门关注DDD，它可能会从中找到想法/灵感。 [在这里阅读更多相关信息。] [3] （项目已经死亡）
我真的很感兴趣：您认为DDD的哪些方面对您有益？ “领域驱动”方面，或实施方面？
答案 1 :(得分：3)
1：取决于。 C＃中的值类型用于原子pimitives（int，byte等）。如果你有类似的东西 - 这是有道理的。如果您的值类型较大，则为。
2：不。一般来说，这不是语言功能。
我建议下一篇：Scott Ambler的“构建对象应用程序”。
答案 2 :(得分：2)
1 - 如果语言支持，值类型应该是真正的“值类型”吗？
我认为答案取决于应用程序中的使用情况和其他因素，但您可能正在寻找的模式是“数据传输对象”，它具有属性，getter和setter，但没有别的。它可以是结构或对象，对象可能会简化内存管理问题，尤其是在装箱方面。
2- C＃中是否有任何特性使语言和模型之间的关联更加清晰（例如，这是一个实体，这是一个聚合等）。
我会选择命名约定，例如“CustomerEntity”，“OrderAggregate”等。
好问题;我期待看到回应。
答案 3 :(得分：1)
1 - 如果语言支持，值类型应该是真正的“值类型”吗？例如C＃中的结构
不要混淆“值对象”的DDD概念和“值类型”的CLR概念（C＃中的结构）。前者与设计有关，后者是较低级别的实现考虑因素，实际上与内存管理有关，而不是其他任何事情。
2 - C＃中是否有任何功能可以更清楚地说明语言与模型之间的关联（例如，这是一个实体，这是一个聚合等等。）
在处理实体与价值观时，是的。我们发现在C＃中使用readonly对于在DDD中实现Value Objects非常有帮助。我们在Pluralsight上大力采用DDD，我不时在Pluralsight博客上发表这篇文章。事实上，我已安排两篇关于readonly和DDD的博客文章将在本周晚些时候发布。