第3章 专注于核心领域

第3章 专注于核心领域

 

1. 为何要分解一个问题域

为理解一个问题域的最有价值的区域，我们需要提炼它以揭示核心内容是什么。

通过分解大的问题域，我们可以更有效地为不同区域分配资源，以确保最有能力的开发人员理解对于业务最重要的区域，而非可能更具技术挑战性的区域或者利用新的基础设施框架的部分。

 

1. 如何捕获问题的实质

要弄清楚你在何处集中精力，你首先需要理解是什么值得你对应用程序进行设计。

需要理解业务战略，以及为何你在创建的软件投入使用后能够实现业务战略。

 

1. 1. 超越需求

一旦你共享和理解了客户的真实需求，你通常就能提供了一个更好的解决方案。

对于一个产品，你是推动者，不要盲从用户的需求。业务用户不能描写有效的特性或者有效阐述目标。

你必须共享和理解其隐含的愿景，并了解业务尝试达成的目标，这样就能提供真正的业务价值。

 

1. 1. 为达成什么是核心内容的共识而捕获领域愿景

在开始参与产品开发之前，一定要寻求一份项目概述。

这份文件通常会包含核心领域的关键内容，该文件是证明了为何编写软件是一个好主意的证明文件。并且将这些信息同步给团队成员。

一份领域愿景说明了可以在项目初期阶段创建，以便显式铺货什么内容对于软件的成功是主要的，业务目标是什么以及其价值在哪里。

 

1. 如何专注于核心问题

大的问题域可以被分割成子域以管理复杂性并将重要部分从系统的其余部分中分割出来。

子域是抽象概念：不要将子域与公司的组织结构混淆。

子域名表示能力区域，定义业务过程，并且代表系统的设计设计能力。

当你在分析问题空间的时候，尽量不要讲技术问题带入沟通交流中。

1	通用域 大多数企业可能都有，例如报表，通知需求等
2	核心域 将你提供的独特产品与竞争对手产品区分开来的区域以及界定赋予其在市场中竞争的内容被称为你的核心区域
3	组成大规模应用程序的其余子域被称为支撑域，他们是核心领域与系统的促成要素。

 

1. 1. 提炼问题域

核心领域是软件取得成功的关键，这一知识是从知识提炼环节与领域专家协作过程中提炼出来的，以便理解当前开发的产品最重要方面。

1. 1. 核心领域

通用域几乎可以不开发，或者直接购买，或者外包出去开发。

但是核心域必须使用最好的开发人员。

随着时间的推移，什么是核心域也会发生变化，所以核心域必须演化。

 

1. 1. 将你的核心领域当作一款产品而非一个项目

通常一款业务产品的软件开发永远不会结束，相反处于开发过程中的产品将在功能增强的各个时期持续存在。

理解你在开发的产品的价值，以及它会给公司带来哪些投资回报，ROI，与你的业务资助方就产品的未来进行讨论，以帮助你集中编码注意力，弄明白什么对他们来说是重要的。

出于快速试探市场，可以出具雏形产品。

 

1. 1. 通用域

通用域，比如：电子邮件发送服务，账户套件，或者报表等。

可以简便快速方式构建。

 

1. 1. 支撑域

支撑域，用于支撑你的核心领域。

比如亚马逊的产品目录浏览功能。

 

1. 子域如何决定解决方案的形成

 

1. 并非一个系统的所有部分都会经过良好设计

在每一个子域中，都会有一个表示与系统相应区域相关的领域逻辑和业务规则的模型。

并非所有的这些模型具有同等质量。

不要再不重要的子域中浪费你的时间和精力，确保放在核心领域上。

可以允许通用语，支撑域的BBoM存在，只要不污染你的核心域即可。

 

1. 1. 专注于清晰边界而非完美模型

允许BBoM域的存在，但是要做个边界处理。

可以使用衣柜防止损坏层阻止一个模型弄乱另一个模型。

 

1. 1. 一开始核心领域不必总是需要完美的

不要讲求完美，讲求实效。

 

1. 1. 构建用于替代而非重用的子域

在子域开发模型中，要出于替代而非考量单独尝试构建他们。

通过使用功能清晰的边界将他们与其他模型，遗留代码和第三方服务分割开来。

通过使用替代而非重用而编码，你就能创建足够好的支撑域，而无需浪费精力力求其完美。

1. 如果没有核心领域怎么办

如果发现你正在构建的软件都是通用或者是支撑企业其他应用程序的，而因此该软件不具有核心领域，那么不许要尝试将DDD应用于你所有的项目中。

1. 要点汇总