现在大家都说框架、架构，就不得不先提分析与设计，谈到了DDD，又不得不谈OOA/OOD。

一套框架，首先是一套方法论，离开理论支持的框架很难长久的发展下去，框架是长期积累的结晶。能够从需求沟通、流程方案、系统设计、快速开发、细调等各个环节，能够无缝的衔接起来，最好能够用同一种声音说话。

BPM，我不知道在国内的项目里面，有多少个公司是真正的在用，当前都用到了什么程度，在作需求的时候是如何处理的。

我在流程引擎选型的时候花了很多的时间，由于没有什么资源，最后是选择了BPMN，因为自己长期以来的分析方法是活动图+状态图的方法，而且通过流 程分析直接能够与框架结合起来，并且映射到服务上去，能够做到流程细化完了，接口、函数基本都可以定下来了，比较能够贴近开发。

流程分析设计，可以直接在系统里画图，画完保存后，大的方面已经定义好；通过UML静态图把数据模型定义好，再把流程的关联对象、脚本、通用服务、界面加入后，就可以直接执行了。而且，后续的脚本、界面，是编码人员应该处理的。这样一样，角色的定义人员分工明确。

最为最为关键的是：BPMN让业务分析、需求分析人员与用户以同一种语言在说话，即使客户从来没有接触过，15分钟后，你所画的图，用户也都能看的 懂，能够提出你画的是否正确，是否把他的意思表达清楚了，你是否把他的想法表达清楚表达全了，与用户之间的不会产生歧义，软件出来后，流程方面与用户的期 望之间通常不会有多大的出入，可能界面方面会有些差异，但如果仅仅是界面的多一个字段少一个字段，对整个项目来说 ，影响通常会相对比较小的，如果再加上快速的界面设计，差异可能会更小。另一方面，与开发人员之间的沟通，也会把用户的意思完整的表达给开发人员，实现意 思的完整传递，使整个项目快速上线。从几个大的客户那边的来看，没有出现过大的返工的现象，整个项目的推进速度应该是非常快的。

这样基本上就可以实现模型驱动开发，这是我的理解，不知道有多少偏差。

举个例子，订单，订单包含明细，明细包含编码。

在流程分析的时候，订单是作为一个整体，明细是因为订单在存在而存在，离开了订单明细没有任何意义。按照封装的原则，服务对外只提供订单，订单内部 归内部处理。订单流转的时候也是作为一个整体，在处理订单详细的时候，用相关子流程处理，从而实现一层层细化。也就是流程+子流程+静态图的抽象。

不知道我说的是否清楚，没有说清的话，请留言，我再解释

下图为我在其中的一个项目里面的与SAP的交互图，是与生产相关的。

流程画完后，与SAP之间的接口也同步定义好了，当场没有定义出加工单的详细字段，在后续细节设计的时候还是应该很容易的设计出来的，至少这一块的 影响不会大。不过，这张图并没有完全按照严谨的流程图去画，重点是为了与用户沟通他们的操作的动作，是一个生产控制系统，业务系统可能会更严谨一些。

这是系统间的，对于系统内部，也是一样的思路与方法。

这张图与业务流程就更吻合一些，当前的这个流程稍加整理就可以通过流程引擎进行流转。

通过静态图可以把结构定下来，这张图可以把几个关键的字段定下来。

这就是我所说的，流程+子流程+静态图+界面，固定的操作可以通过Coding的方式把写进服务，而不是通过流程引擎或脚本去处理，比如增加、减少库存等等。不用流程引擎，则函数接口也定义出来了，差异也不会太大了。

这就是我理解的DDD，这是我用的分析方法， 在实际项目中自己感觉还是比较好用的，在还没有流程引擎和静态图工具的时候，就是通过这种方法把流程 定位到服务，数据库设计通过工具生成代码，然后再手工改代码与静态图一致这种方法实现了，手工映射到框架上去的。我的框架支持层次级联触发的，是树状态结 构，能够实现服务、对象的映射。

至于实际的分析设计，还需要深入的学习和实践的积累。