上面的内容也可以通过UML中的活动图来描述。但是，这里的描述方式更接近于一个故事。这是我喜欢的形式。

仔细看看上面的描述，是不是感觉有点味道了？这个故事所需要的计算（服务）都已经很清楚了。注意，在这个设计阶段，不要急于进入细节，不要去追问参数传递的问题、上下文范围的问题等。急于进入细节是设计人员的大忌。

      事实上，我们正在循序渐进地思考。

如果你是一名从事大连保险行业软件的设计人员，一定会对上面故事中的计算（服务）很敏感。那些计算（服务）包含的业务含义需要大量的领域经验。不过，领域经验也不在本书的讨论范围。我想要讨论的是——接下来要怎么做呢？

      在对故事中的业务含义进行分析之后，我们可以把计算（服务）分成了几个相对独立的大类：

      保单相关的；

      客户相关的；

      折扣相关的；

      佣金相关的；

      共保相关的；

      致远服软认为：http://www.soft8.com.cn/每个相对独立大类中的服务，可以由一个组件来承载。老实说，我在这里定义的分类，大连保险行业软件开发抽象层次都比较低。对于大连保险行业软件有兴趣的读者可以去了解一下IAA标准。IAA标准提供了一个更加灵活、抽象层次更高的组件模型。

      顺便插一句，企业应用应该尽可能地向标准靠拢。其实，每一个标准都是领域专家的宝贵经验。在质疑某一个标准不能解决你的实际问题之前，要非常认真地问自己一个问题，你真的理解标准了吗？通常情况下，为了所谓的“实际问题”而放弃标准，大多是使用者自身的问题，而不是标准的问题。另外，采用标准可以最大程度地简化问题，从而为大连保险行业软件开发组织带来巨大的利益。

让我们回到正题。根据计算（服务）的分类，我创建了一些组件：

      CoPolicy

      CoPersonInfo

      CoDiscount

      CoCommission

      CoCoPremium

      实际上，在对计算（服务）进行分类和创建组件时，有一些取舍裁剪的原则。这些基于原则的思考才是最重要的。我的思路是：

      在同一抽象级别上提供计算（服务）。例如，关于折扣的故事，关于佣金的故事。当然，这取决于设计者的视角；

      组件具有高内聚、低耦合的可能性。例如，只有在涉及折扣时，才会与折扣服务相关。折扣的业务逻辑可以独立地变化。

      有了服务和组件，设计工作开始变得比较具体了。我们可以拿着这份大连零售会员管理软件开发设计成果与更多的涉众进行讨论，例如，客户和业务分析人员等。我们有故事、计算（服务）分类的理由、业务含义明显的组件、涉众的反馈，后续的微调工作应该没有什么问题。