使用DDD的业务价值
如果你的经验和我相当，你就应该知道软件开发者不应该只是热衷于技术，而是应该将眼界放得更宽。我认为不管使用什么技术，我们的目的都是提供业务价值。而如果我们采用的技术确实产生了业务价值，人们就没有理由拒绝我们在技术上的建议。
如果我们提供的技术方案比其他方案更能够产生业务价值，那么我们的业务能力也将增强。
业务价值最重要吗？
当然啦，我甚至都在想是不是应该将“使用DDD的业务价值”这一节再往前放一些。更确切地讲，该章节的题目叫“如何向你的老板推销DDD”更为合适。我并不希望你将本书看作只是些理论，而是希望本书对你的公司具有实际的指导意义。
让我们来看看DDD所带来的一些非常理想化的业务价值。记得将这些分享给你的管理层、领域专家和技术人员。我们可以将DDD的业务价值大致总结为以下几点：
你获得了一个非常有用的领域模型
DDD强调将精力花在对业务最有价值的东西上。我们并不过度建模，而是关注业务的核心域。有些模型是用来支撑核心域的，它们同样是重要的。但是，这些起支撑作用的模型在优先级上没有核心域高。
当我们将关注点放在自己的业务和别人业务的区别上时，我们便能更好地理解自己的任务所在，同时我们将更具竞争优势。
你的业务得到了更准确的定义和理解
业务人士能够更好地理解业务本身。我甚至听说通用语言曾经出现在某些公司的市场营销材料中。
随着业务模型的不断改善，人们对业务的理解也将更加深刻。在团队讨论的过程中，一些业务细节被不断地暴露出来，这些细节有助于掌握业务价值。
领域专家可以为软件设计做出贡献
当人们对自己的核心业务有了更深的了解时，业务价值自然就出来了。领域专家并不总是同意某些概念和术语。有时，分歧源自于领域专家们在其他公司工作时所积累起来的经验，而有时分歧则源自于公司内部。不管如何，当领域专家们在一起工作时，他们最终将达成一致意见，这对于整个公司来说都是件好事。
开发者和领域专家共享同一套交流语言，领域专家将知识传递给开发者。开发者总是会离开的，有可能去接触一个新的核心域，也有可能跳槽到其他公司，这时培训和工作移交也将变得更加简单，而“只有少数人才了解模型”的情况将大大减少。领域专家、剩下的开发者和新进人员可以继续使用通用语言进行交流。
更好的用户体验
用户体验可以更好地反映出领域模型的好坏。
如果软件留下太多的地方让用户自己去理解，用户往往需要经过培训才能做出操作决定。实际上，用户只是将他们所理解的转移到表单(form)中的数据而已。数据将被存储起来，如果用户不知道数据的用途，那么结果也将是错误的。
当用户体验是按照领域专家心中的模型来设计时，就不会出现以上的问题了。这时软件本身便能对用户起到培训作用，而不需要业务人员来提供培训。效率提高了，培训减少了这就是业务价值。
接下来我们看看技术为业务创造的价值。
清晰的模型边界
我们并不鼓励技术团队将精力单纯地放在编码和算法上，而是期望他们能够面向业务。明确的目标产生高效的解决方案，而要达到这样的目的往往需要更好地理解项目的限界上下文。
更好的企业架构
一旦限界上下文得到了较好的理解和仔细的划分，那么团队的所有成员应该知道限界上下文间的集成是必要的。上下文之间的边界和关系是明晰的。当不同上下文的模型间存在依赖关系时，我们将使用上下文映射图来集成不同的限界上下文，而这又有助于我们全面地了解整个企业的架构。
敏捷、迭代式和持续建模
“设计”这个词可能并不能取悦业务管理层。然而，DDD并不是一个重量级的设计方法和开发过程。DDD并不是画模型图，而是将领域专家的思维模型转化成有用的业务模型。DDD不是创建一个真实世界的模型，而是模仿现实。
团队的工作遵循敏捷方法一一迭代式的，增量式的。任何一种敏捷方法，只要团队认为合适，都可以用于DDD项目。通过DDD创建出来的模型便是可工作的软件。团队会对模型做持续的改进，直到业务层没有新的需求为止。
使用战略和战术新工具
限界上下文为团队创建了一个建模边界，成员在边界内部为特定的业务领域创建解决方案。在单个限界上下文中团队成员共享一套通用语言。不同的团队有时各自负责一个限界上下文，此时可以使用上下文映射图在战略层面上对限界上下文进行界分和集成。在某个建模边界内部，团队将使用战术建模工具：聚合(Aggregate, 10)、实体(Entity, 5)、值对象(Value Object, 6)、领域服务(Domain Service，7)和领域事件(Domain Event，8)等。