坦克模型领域知识的积累
驱动
“驱动”这个词近些年来不绝于耳，耳熟能详的如:用例驱动开发 （UDD）、特性驱动开发（FDD）、测试驱动开发（TDD），驱动的本质是什么？
“驱动”就是试图让我们的思路更顺畅，场景的切换更平滑。“领域驱动设计”就是希望在我们的设计中首先体现的是核心领域的选择和实现。我们做出来的设计跟所选择的领域之间更具有可追溯性、可度量性。
领域发生了变化，领域模型和设计就要发生相应的变化;设计变化了，一定能够追溯到领域的变更。引发设计变化的因素很多，一定要是关键的领域部件所带动的。
坦克模型模型
虽然，我们可以从众多的线索中抽取出比较核心的部分（也就是领域），但是领域还是太大，所以我们需要对领域的不同的侧面进行描述，以期团队成员可以很好的跟领域专家进行沟通，不至于在若干的岔路前迷失。
领域专家
为了获得真正的领域，应该让领域专家进入团队。这个角色对于项目的成败至关重要。请紧记，一个项目团队之所以能够正确地从业务线索中筛选出核心领域，其前提是团队中有一个真正的“领域专家”。而现在我们通常见到的是让一些技术人员去“编写”需求。
那么将上面的词汇进行汇总，我们最后能够得到的是什么？
如果要做到“领域驱动设计”，那么我们需要和真正的领域专家一起工作，从众多的线索中，筛选出最能够体现核心业务价值的领域，为它建立一个可以设计和实现的领域模型，并在团队中始终使用这个模型进行交流沟通。
坦克模型常规项目的领域建模6步法
如果不考虑太多的因素，只是想在项目团队中实践“领域驱动设计”，那么我们可以遵循一个简单的6步法。
1.提取概念。在这一步骤中，应该尽量多的进行领域走查，从文档资料或者交流过程中发现并标记出更多概念，尽管这些概念会有重复或者被混淆的可能，尽量先不要打断自己的或者领域专家的思路。
2. 标注关系。概念的关系会有很多种，但最重要的就是两种，关联关系和泛化关系。因为两个概念之间可能有若干种关联关系，所以，应该在每一个关系关系上标记关联方向、关联名称和多重性。注意，关联应该尽量根据业务逻辑形成单方向的关联，关联关系的箭头方向也不要跟数据模型中的外键关系相混淆。尽管目前出于各种原因，很多的语言很难实现出这种强语义的单向关系，但作为对业务的深入理解，将其简化更容易消除我们思维中的领域复杂性。
3. 分清类别。目前存在很多种对领域概念的分类方式，DDD中提出的分类方法是:实体、值对象、模块、服务、资源库、限界上下文等，Peter Coad在自己的《Java Modeling in color with UML》中提出了自己的分类方法，如Party/Place/Thing，时间/间隔等，还有我们最常使用的系统、子系统的分类方法。
我个人的实践观点是，不一定要选择哪一种固定的分类方法，应该根据业务的实际情况，合理的选择一种或者几种分类作为自己的分类方法。
4.坦克模型深究疑问。可能有人对为什么要进行分类（第3步）心存疑惑。分类的最大的目的是为了形成高内聚低耦合，其次通过分类，还能够让我们将分类剩余的或者类别中不和谐的部分查找出来。对于任何疑问，都应该记录下来，并且应该找领域专家进行讨论，并澄清其中的概念。
在深究疑问的过程中，经过一定的领域知识的积累，可能会达到从量变到质变的突破。虽然突破很难出现，但只要它真的出现，就会给整个团队带来一种新的开发思路，领域的复杂度往往会随着“突破”的出现而发生变化。
其实在现实生活中，我们眼见后第一感觉并不一定就是真实的领域逻辑，比方说，我们会在日常的交流中大量的使用规约（Specification）:“某文档创建人的所有的直线上级都可以查看该文档”这句话经过领域建模后，可能会形成以下的要记录的规约:“某种文档类型，其创建者在‘行政编制’中的所有的直线上级都具有‘查看该文档’的权限”;而“办理资产入库登记”会演变成“登记某种资产类型的一批号段的批量入库”。
5. 映射到数据模型并实现。作为企业级应用，大部分的领域模型是要被存储下来的，包括那些隐式的概念。隐式的概念的处理有两种方式，一种是直接运算后记录运算结果;一种是记录下规约，在运行时解释。前一种方式的执行速度会很快，但是规约适用的范围发生变更时调整起来比较麻烦，后者执行时运算速度慢，但是应对变化能力更强些。因此，可以将这两种方式结合，同时记录规约和规约运算的结果。
我们现在在项目团队中的做法是，是将核心领域中的业务需求细化成可度量的用户故事，采用“测试驱动开发”的方式整理测试用例和测试夹具（fixture）。这种方法的好处是整个的需求把握是从领域模型出发的，不会将需求的覆盖和设计的推导寄托在持“技术思考”的开发人员身上。通过实现带有检查点的用户故事，提炼出来的接口往往是最实用的，会对“预先设计”产生的工件产生改天换地的效果。
6.就如同“降龙第十八掌就是要将前面的十七掌连起来再打一遍”一样，坦克模型是一个迭代的过程，需要根据变更的情况对领域模型进行重组和调整，为了方便的进行重构的同时保证质量，应该在项目团队中实施自动化的项目构建，并确保持续集成。
相关信息：