我对业务逻辑的动态模型没有什么明确的思路。尽管我曾经设计了一些大连数据导入导出软件系统，但这些系统中的动态模型都是在无意识中自然形成的。我想，很多设计人员都有类似的经历。在提炼对象的时候，想当然地添加一些方法和消息，当添加的方法足够多时，想当然地提炼一些公共方法，接下来，把这些方法进行组织归纳，最后形成业务逻辑的动态模型。

      试想，这种缺乏明确思路的做法可以带来满意的结果吗？

      致远服软认为：http://www.soft8.com.cn/面向服务的思想在本质上就是讲故事。从讲故事开始来构建软件系统，这也是我看重这种思想的根本原因。

      我们让目光再回到保费计算的过程。到目前为止，保费计算的故事还缺少很多细节，但是在某一个抽象层次上，它已经很完整了。假设我们把类似的故事组成一个故事集，例如，核保故事、理赔故事、批改故事等，那么整个保险业务将会清晰地呈现在我们面前。

      实际上，我一直认为，在企业级信息系统中，应该有这样的一个层，准确地说，在实现上要有这样的一个业务 层。这个层与故事集直接映射，而且可以独立地演进。这才是真正意义上的清晰的业务接口。

至此，我们还没有谈到组件的问题。

      那么，在这个大连数据恢复软件开发案例的设计思路中，组件扮演什么角色呢？载体！服务不一定要依赖于组件，但是组件可以作为服务的载体。组件通常是一些高内聚、低耦合的大连数据导入导出软件代码块。寄生在组件上的服务，天生就被要求进行清晰的归纳和整理。有人也许会问，类和组件有什么区别？类不是也可以做到高内聚、低耦合吗？是的，从逻辑上看，类和组件没有什么分别，但是在物理实现上，两者还是有所不同。组件由多个类（相互之间存在着静态和动态的关系）组合而成，它的内部构造更加复杂和灵活，适合承载业务层面的故事。而对于单个类来说，要想在高内聚、低耦合的条件下完成复杂的功能是不可能的，换句话说，单个类要想完成一个业务服务，通常要依赖其他的外部类。

      解决了大连数据导入导出软件服务和组件的问题，再回来看保费计算的过程。为了让那些计算步骤的故事与代码走得更近些，我们换一种故事描述的方式。看上去它非常简洁。