DDD实践切入点实践切入点
之前大致说了使用DDD的前期准备，现在可以真正开始实践了，以我刚刚结束的一个简单的经典DDD方式的项目为例子，当
然由于比较简单，所以很多时候会脱离它来介绍一些额外情况，以及这些情况在《DDD》书上提到的解决办法，另外，说明
一下，例子的作用只是例子，只是用来说明可以怎么做的，但真实情况时未必应该这么做。这一篇主要是大比例结构的。
首先，简单提一下项目背景，具体情况就不细说了。今年初公司重组，原本的一个公司拆分成了三个公司，信息化部门还是只
有我们一个，经过小半年的时间，业务终于差不多确定下来了（稳定不稳定不好说），我也终于接触到了真实的业务（以往由
于某些原因全是凭空猜的），作为例子的这个项目是做流程审批的，以此为基础分析后，发现非常适合使用DDD的方式进行
设计开发。
前一篇提了，开始一个项目最重要的是要做的是确定需求中的核心问题，项目对公司来说目的是提高办公效率，而对我的领导
来说更关心的是业绩，也就是开发效率，毕竟是公司内部系统，速度在一定程度上优先于其他。我做架构设计，我需求的核心
也就是如何让程序员写更少的代码，更快开发出功能，这一点在架构设计开发过程中会占主导地位。
当然，前提是得满足完成业务的基本要求。在开始架构的设计前首先要确定系统的范围，系统都有什么，也就是一般说的系统
边界。
可以使用大比例结构来确定系统的边界，当系统比较庞大时，可能会分为很多个模块，太多的模块依然会给人的理解造成压
力，而Bounded Context虽然可以包含多个模块，但很容易让系统难以成为完整的整体，这时使用大比例结构可以让人清楚的
看出系统的整体，借助一种更大范围的划分，可以清楚的理解元素在系统中位置。这时，当要寻找一个对象的位置，或新增一
项功能的时候就可以轻松的定位到要找的位置，负责不同模块的人也可以清楚的知道自己所要做的部分对于总体和对于其他部
分的作用，分工不同的程序员所做的设计决策可以大体上保持一致。
我的例子不大，使用大比例结构意义不大，基本可以分成两块，一个是审批申请单，一个是审批流程。审批流驱动原本的暂时
还能满足需求，所以只需要设计申请单的处理就可以了，之后的事情虽然很简单，但是为了让它起到例子的作用，先来对它使
用下隐喻，比如说，审批流是一个生产产品的流水线，申请单作为原料一步一步被附加各种加工也就是意见，最后成品的产品
即审批结果。
对于业务比较复杂，模型中对象很多，无法一下清晰完整了解模型意义的，可以使用一些对模型分层的方法。这些分层方法的
目的是使开发变得更容易。
一、Responsibility Layer模式：如果每个对象的职责都是手工分配的，将没有统一的指导原则和一致性，也无法把领域作为一
个整体来处理。为了保持大模型的一致，有必要再职责分配上实施一定的结构化控制。观察模型中的概念依赖，领域中不同部
分的变化频率和原因。如果领域中有自然的层次结构，就可以作为主要的职责。这些职责描述了系统的高级目的和设计。领域
中的对象的职责都应清晰的位于一个职责层中，层都应该反映出现实状况，而不是设想的状况。
当需要按职责分层时，可先分为作业层和潜能层分别包含“作业”职责和“能力”职责，如果有需要根据业务制定决策时增加决策
层，如果可以将指定决策的规则抽取出来时策略层，以及介于作业和策略之间的承诺层，Evolving Order具体使用需要看自己
情况随机应变，具体哪种方法好，要不要这么分层都是根据自己的实际情况决定的，感觉到别扭就要考虑换一种方法，切忌生
搬硬套。
潜能层：资源（包括人力资源）一集这些资源的组织方式是潜能层的核心。这一层关心的是能做什么。潜能也包括临时资产，
但主要依赖临时资产的可将临时资产独立一层，比如Capability层。
作业层：正在做什么，利用潜能做了什么。通常作业层对象可以引用潜能层对象，甚至可由潜能层对象组成，但潜能层对象应
该引用作业层对象。
大部分此类领域系统中，这两层就够了。它们可以跟中当前状态和执行的作业计划，已经问题报告等。但跟踪往往是不够的。
当项目腰围用户提供指导或自动制定一些决策时，就需要另外一组职责。
决策支持层：应该采取什么行动或制定什么策略。这个层是用来做出分析和制定决策的。它可以对较低层的信息进行分析。它
对较低的层如作业层或潜能层有概念上的依赖。
策略层：软件实施了详细的业务规则或法律需求，这些可以形成一个层次。可以使用规则引擎，也可以作为参数传递给其他层
的方法。
资源评论
