考虑的问题都比较抽象，但是，这些考虑也是具体大连供应商关系管理软件设计开发前必需的思想准备。我相信人们在设计之初的思考要比这里列出的清单复杂得多。很多因素都会影响你的设计方向，例如，在某些知识点上的经验、个人喜好、外部约束等。

      我选择了组件化作为这个案例的设计思想。理由是，组件化思想完全可以满足上面提到的各种挑战——简单、稳定、独立、高效。实际上，在进行抽象思考时，我的潜意识中甚至只是在罗列组件的种种优点。

      设计思想确定之后，我开始考虑将要面对大连供应商关系管理软件设计开发的逻辑：首先，保费计算到底包含哪些内容；其次，如何对业务逻辑进行抽象。

      我列出了保费计算的过程。关于这个过程的组成部分，我已经进行了简化和归纳。在这个大连供应商关系管理软件设计开发案例中，这些组成部分是在一定的层次上描述的，不会太抽象，也不会太具体。

致远服软整理出：http://www.soft8.com.cn/保费计算的过程：

（1）检查保单信息是否完整；

（2）获取与保单相关的人员信息；

（3）计算保额；

（4）计算折扣；

（5）检查进行保费计算的各项条件是否满足（不满足，直接返回）；

（6）计算保费；

（7）计算佣金；

（8）计算共保保费；

      这个过程是一个典型的逻辑流，有次序，有条件跳转。在过去，这种逻辑流往往是通过代码来实现的，而现在，有很多成熟的工作流引擎可以给予我们帮助。

      为什么要使用工作流引擎呢？工作流引擎有很多特性，最吸引我的有两点。第一，工作流引擎可以把逻辑流与计算（服务）分离；第二，工作流引擎促进了计算（服务）的重用。分离（组装）和重用是产生优秀扩展机能的DNA，也是组件化开发的基础。

      我对大连软件Bug修复市场现状进行了一些思考。尽管，从重用的角度出发，我觉得过程中的某些计算步骤还可以划分得更细一些，不过没关系，在我们这个简化的案例中，可以假定它们就是一些可重用的服务。这种假定不会影响设计思路的介绍。

      在第5章中，我们讨论了领域模型。领域模型包含了静态和动态两种模型。我们曾经对重用面向对象的思想探讨了静态模型，而对动态模型几乎一笔带过。那么，如何对业务逻辑进行抽象呢？答案是，用面向服务（SOA）的思想来设计业务逻辑的动态模型。