领域模型与工作流之间的关系

        当涉及审批流程的业务需求按照功能点进行描述时，往往每个用例（功能点）都是按业务岗位进行描述，此时单个用例因涵盖了流程的信息而显得异常复杂，用例与用例之间又因包含相似的信息而显得重复臃肿。
        如果我们选择了以领域建模进行设计，那么这些工作流的需求属不属于领域建模的范畴内？应该如何处理它们之间的关系呢？

        在《领域驱动设计》（DDD）一书中在不同地方均有提及，类似的规则引擎也是可以相应看待。
        首先章节5.6中提到，主流的建模范式是面向对象范式（的确，一说到领域脑子里总会浮出各式各样的对象图，采用面向对象技术的优点也不用再说了），但是领域模型不一定是对象模型，业务规则引擎或工作流引擎属于非对象组件，混合使用不同的范式使得开发人员能够用最适当的风格对特殊概念进行建模，但是使用不同的范式后，要想得到一个内聚的模型就比较难了。
        那么可以分离出两个部分，一个是业务逻辑部分，一个是工作流部分，《DDD》中提到，将各个部分紧密结合在一起的最有效工具就是健壮的ubiquitous language，还有4条经验规则。
        在分层结构（用户界面层、应用层、领域层、基础设施层）中，这两部分应该都属于领域层，他们之间的很少直接联系，通过应用层来调用，使他们互相协作。

        而且，流程的东西就是可以快速变化的，比如多一个审批岗，少一个审批岗。
        那么我们在分析需求时，可以先将工作流的干扰信息剥离，找到我们应该更关心的core domain。