Julie Lerman对于领域驱动设计（DDD）深感着迷并且倍受启发，但在数据驱动开发方面的长期经历，使她在理解如何在DDD中使用自己技能的道路上，不断的挣扎、争论又满腹辛酸。Julie自2003年起成为微软MVP，作为顾问和导师从事.NET平台方面的工作。她认为，或许由许多开发者都遭受了同样的痛苦，因此在MSDN杂志上撰写了三篇文章来分享她所学到的经验教训。 Julie强调，DDD适用于复杂行为——并不是应用的每个部分都会包含这样的问题。对于应用中仅仅涉及简单的创建、读取、更新和删除（CRUD） 的部分，我们或许最好采用非DDD的实现方式，但对于复杂行为和CRUD的结合部分，Julie建议识别出复杂部分，并将其分解为独立的有界上下文，并对 它们运用DDD。 当进入DDD并对某个领域建模的时候，Julie会聚焦于业务，研究所需的任务和行为。数据持久性与业务问题无关，因此它应该扮演支持的角色，而不是去干预领域设计。 Julie遇到的那些麻烦中的一个主题，是在子系统之间分享类型和数据。在她看来，分享类型一直是强制性的，对同一个数据库中的相同表进行操作也是 如此。DDD让她学到，不分享某个领域模型也可能是完全没问题的，因此可以将来自不同子系统的数据的相同类型，存储在不同的表和数据库中。复制数据并不是 一种过错，从长期来看，由于移除了分享数据的复杂性，这或许会简化我们的系统。 在她最后一部分分享中，Julie讨论了一些使用ORM工具的过程中出现的问题——她使用的是实体框架。其中一个问题是单向关系，这是使用DDD时的首选关联方式。最初的DDD书籍作者Eric Evans的建议是，“尽可能地约束关系是非常重要的”。对Julie来说，自打开始使用实体框架以来，双向关系一直是一项规范。然而现在她发觉，尽管双向关系很方便，但在领域中鲜有实际需求，而省去双向关系将会移除关系管理中的部分复杂性。 Julie的文章还给出了一段用C#和实体框架（微软用于.NET平台的对象关系映射工具）编写的例子。 查看英文原文：Experiences Going From Data-Driven Development to Domain-Driven Design |
