如何解决上文提到的鉴定标准中的问题呢？我认为答案就是MDD。
用一个实际的例子来表述一下思路：
在CRM系统有个订单处理模块，其提供了订单管理、订单流程执行、工单管理等功能，营业员通过界面提交一个订单请求，如果订单请求通过业务规则的校验，则会创建一个订单对象，订单对象的创建会触发订单流程的创建，订单流程流转的过程中，会在各个节点创建工单，也会调用其它子系统开通服务，比如调用物流发货。订单流程完成后，订单对象的状态也完成。实际的系统比这个要复杂，这里仅仅为了阐述思路，做适当的简化。
从上面的例子，我们可以识别出几个模型:订单、工单、订单流程，订单、工单、订单流程都是stateful的、其state的变更会导致其它对象的状态变更或者服务的执行。
在展现层，展现各个模型是有章法的，比如创建订单的界面总是一样的，处理工单的界面也总是一样的，展现订单的界面也总是一样的。因此，我们可针对指定的对象的某种需要展现的状态，提供合适的展示构件（WEB TAG）来展示它。
在持久层，因为对象总是持久化到一张表当中的，因此，可用一些ORM的框架来持久化对象，而不是开发人员针对每个场景去写SQL，复杂的关联查询可以使用类HQL。
各对象之间的关联操作通过事件驱动。
举一个订单创建的例子：
1、开发做的工作：
1）使用元数据定义订单的数据结构，包含持久化元数据、基本属性元数据、字典元数据；
2）定义订单状态机，以及状态变迁的规则；
3）建模订单处理流程；
4）定义订单请求处理规则流，并发布为一个受理订单请求的服务；
5）开发订单创建界面，使用订单WEB构件来展示订单对象；
6）定义事件，以及事件的监听服务；
2、系统执行流程：
1）营业员打开订单创建界面，系统获取订单对象的元数据，生成订单创建页面；
2）营业员点击订单创建界面的提交按钮，调用受理订单请求的服务；规则流执行，如果规则校验错误，则返回错误，如果成功，则创建订单，返回成功；
3）因创建订单，导致订单的状态变为创建状态，触发订单创建事件；
4）订单创建的监听服务流程服务接收到事件，触发订单处理流程的创建；
5）流程执行的过程中编排第三方系统服务；流程执行结束后，触发订单流程结束事件，流程结束事件的监听服务订单管理接收到事件，触发状态机变迁，订单状态变为完成。
上述开发做的工作全部可通过配置完成。后续如果增删字段，修改元数据即可，要增删改业务规则，调整业务规则即可，要调整实体状态，修改实体状态机即可。
业务平台要致力于对状态机、业务流程、SEP、元数据、领域化的WEB构件的实现，并将其有机整合。
写的比较乱，过几天再整理一下。。。