【IT168 技术文章】

    对于一个已经初步建立好的模型（分析模型或是设计模型）来说，对其进行精化和合并是必要的步骤。

    建立架构愿景，为架构的设计定义了主要的设计策略和实现思路。应用分层的原则则对整个的软件进行了结构上的划分，并定义了结构的不同部分的职责。而现在，我们需要对初步完成的模型进行必要的改进。

    我们如何对初始架构模型进行改进？

    对模型进行改进的活动可以分为精化和合并两种。我们先从精化开始。

    首先，我们手头上的初始架构模型已经包括了总原则（参见架构愿景模式）和层结构（参见分层模式）两部分的内容。现在我们要做的工作是根据需求和架构原则来划分不同的粗粒度组件。粗粒度组件来源于分析活动中的业务实体。把具有很强相关性业务实体组合起来，形成一个集合。集合内部存在错综复杂的关系，同时集合向外部提供服务接口。这样的集合就称为粗粒度组件。粗粒度组件对外的接口和内部的实现是相区分的。粗粒度组件的形式有很多，Java平台上的Jar文件、Windows平台上的dll文件，甚至古老的.o或.a文件都可以是粗粒度组件的表现形式。设计优秀的粗粒度组件应该只是完成一项功能，这一点是它与子系统的主要区分。一个系统中可能包括会计子系统、库存管理子系统。但是提供会计粗粒度组件或是库存管理粗粒度组件是没有什么意义的。因为这样的粗粒度组件的范围过于广泛，难以发挥重用的价值。

    粗粒度组件是可以（可能也是必须）跨越层次的。粗粒度组件拥有持久化的行为，拥有业务逻辑，需要表示层的支持。这样看起来，它所属的轴向和层次的轴向是相互垂直的。

    粗粒度组件来源于需求。需求阶段产生的需求说明书或是用例模型将是粗粒度组件开发的基础。在拥有了需求工件之后，我们需要对需求进行功能性的划分，将需求分为几个功能组，这样我们基本上就可以得到相应的粗粒度组件了。如果系统比较庞大，可以对功能组再做细分。这取决于粗粒度组件的范围。过小的范围，将会造成粗粒度组件不容易使用，用户需要理解不同的粗粒度组件之间的复杂关系，最后的结果也将包含大量的组件和复杂的逻辑。过大的范围，则会造成粗粒度组件难以重用，导致粗粒度组件称为一个子系统。

    假设我们需要开发一个人力资源管理系统。经过整理，它的需求大致分为这样几个部分：

    组织结构的设计和管理：包括员工职务管理和员工所属部门的管理。

    员工资料的管理：包括员工的基本资料和简单的考评资料。

    日常事务的管理：包括了对员工的考勤管理和工资发放管理。

    对于前两项的功能组，我们认为建立粗粒度组件是比较合适的。但是对于第三项功能组，我们认为范围过大，因为将之分为考勤管理和工资管理。现在我们得到了四个粗粒度组件。分别是组织结构组件、员工资料组件、员工考勤组件、员工工资组件。

    在得到了粗粒度组件之后，我们的工作需要分为两个部分：第一个部分是定义不同的粗粒度组件之间的关系。第二个部分是在粗粒度组件的基础上定义业务实体或是定义细粒度组件。