度过初创期，业务复杂性明显发展，系统结构和质量越来越受到重视。

需要考虑如何管理领域¹。

什么是领域？

领域是业务概念和他们之间的关系与协作。系统的目的就是实现这些概念和协作。

领域有什么用？

1. 领域决定系统的业务特征。领域的现状就是系统的业务现状，领域的历史就是系统的业务历史。或者说，领域体现了业务与系统特征间的因果关系。
2. 领域是通用语言。在产品团队与开发团队间，各产品线之间，各开发团队之间或者开发团队内部。领域是沟通的语言，也是发布和积累的语言，是协作的首要工具。
3. 领域是系统结构的依据。以领域驱动设计²是应对系统复杂性的常见手段。领域的结构深刻影响系统结构。

这些用途决定了对领域管理的要求，比如：容易阅读，容易查找，容易控制，容易共享，容易跟踪变化。

如何管理领域？

1. 从静态、动态两个角度描述领域。静态体现领域实体和他们的关系，动态体现领域实体的行为和协作。可以借用UML类图和序列图的形式³，也可以使用伪代码。
2. 形式化、结构化的描述体系。形式化的语言去除二义性，知识在各团队各角色之间不会产生歧义。结构化的语言体现层次，不同角色可以关注不同层面。 这一点上，UML相关约定完全够用。如果结合文件系统的树形结构，可以实现足够丰富的层次。
3. 使用git或其他SVC。便于共享和跟踪变化。这要求使用尽量简单的描述语言。在这里，一般的UML图不太理想，人类无法阅读UML图的diff。同样的，各种其他图、doc文档之类也不理想。可以借用马丁大叔UmlAsSketch⁴的想法，使用纯文本形式的UML。
4. 使用中文。英文翻译是引入歧义的重要途径，在尽量少的地方使用英文，而不是相反。
5. 与开发共享周期。领域变化的步调一般与系统的设计开发一致，可以借用设计开发的版本和迭代周期。

另外，一些可能的问题——

Q：领域是需求么？
A：对于开发团队来说，可以说领域来源于需求。区别是：

1. 需求从产品和用户的角度，以交互驱动；领域从设计和开发的角度，以结构和逻辑驱动。
2. 需求是增量，领域是全量。需求描述的是每次改动，一般以版本、迭代作为组织单位。如果想从需求知道系统体现业务现状，就必须将历史中所有相关需求找出来进行归纳，这无疑非常困难。而领域持续维护，随时体现当前现状。
3. 需求关心局部，领域关心全局。需求强调体验，往往专注于局部，以一个场景一次交互为单位进行描述。而领域强调整体，需要负责跨产品线跨系统保持一致性。
4. 需求包括功能、质量、约束，领域只涉及到功能。

Q：领域是设计（类图、ER图……）么？
A：领域是设计的依据（之一）。设计的目的是实现领域，但设计需要同时考虑其他架构策略，比如由质量要求引发的技术方案。如图：