面向服务的分析和设计(SOAD)

 1、SOAD总体指导原则

     - 经过良好构思的服务应该给业务带来灵活性和敏捷性，它们通过松耦合、封装和信息隐藏等机制使服务的重新配置和复用更加容易

     - 设计良好的服务之间的依赖被最小化而且被显式声明，最小依赖原则不仅仅适用于企业应用

     - 服务抽象是内聚、完整和一致的。

     - 服务是无状态的，但可以减弱该假设以切合特定的问题域和场景

     - 对服务的命名要做到能使其没有较深技术知识的领域专家理解

     - 在某个SOA应用中，所有的服务都要遵循一致的设计哲学和交互模式，并且支撑应用的体系结构风格要鲜明以便于识别

     - 服务开发者和服务使用者在具有领域知识外，仅需基本的编程技能；只有少数专业人员才需要专门的中间件知识。

2、SOAD过程框架

（1）服务识别

      目的是定义系统功能，并把系统功能合理地组织成服务。

      从业务域出发，对业务域进行分解和分析是服务识别的主要途径；由于自顶向下和自底向上识别服务难免不够全面，此时可以利用“目标-服务”对应建模方法（goal-service modeling)，以项目目标为基准，检验已识别服务的完备性。

      进行服务识别时要掌握服务粒度原则和命名规范原则

      服务粒度原则：基本原则是粗粒度(coarse-grained)，可用Facade模式

      命名规范原则：需要定义企业级别的命名模式。借鉴OO的最佳实践，用名词给服务命名，用动词为服务的操作命名。

      包括：
      a. 领域分析：业务驱动的，自顶向下的服务识别活动。从业务角度，领域是一组业务功能域的集合。业务用例通常是业务服务的极佳候选
      b. 现存系统分析：自底向上，分析现存遗留系统以识别服务的活动。现存系统作为实现部分业务过程功能的低成本解决方案，其相关API、事务、模块经过分析后提升为服务。有时，遗留系统需要构件化以支持服务功能。
      c. “目标-服务”建模：服务识别的目的是发现和整个组织业务相匹配的服务集，“目标-服务”建模活动的目的是测试领域分解和现存系统分析识别的服务的完整性，并适当地补充业务需要而未识别的服务。

（2）服务编目和聚集
      该活动在服务识别完成后进行。把服务进行分类编目有利于服务的使用，比如业务服务和技术服务显然有不同的功能和目的。通过服务聚集可以把细粒度的服务组合成更大粒度的服务，从而可以克服由于过多的细粒度服务存在而引起的性能、可伸缩性以及管理等问题。

（3）服务和构件规范
      该步骤包括子系统分析、构件规范和服务规范活动。
      a. 子系统分析：把在领域分解阶段定义的业务用例求精为支持特定业务过程的系统用例，并识别子系统接口、业务构件、技术构件以及相互之间的依赖和流程关系。
      b. 构件流程规范：该活动定义实现服务的构件细节，包括定义构件的数据、规则、服务、可配置的profile以及可变更项。
      c. 服务规范：该活动详细定义服务的功能、非功能属性以及服务包含的具体操作。对复合服务还有定义其包含的服务的编排细节。
      d. 服务流程规范

（4）服务实现：包括服务到构件的分配和服务实现决策。
      a. 服务分配：服务分配活动把服务分配给各个子系统，这些子系统包含能实现服务功能的构件。这样服务不仅可以向上回溯到对应的业务目标，而且也可以向下定位到实现服务的构件。
      b. 服务实现决策：决定哪些服务用遗留系统模块实现，那些服务从零开始实现。其他还有集成、转换、订阅、部分外包等实现方法。影响服务实现决策的因素除了业务功能方面的考虑外，服务的安全、管理等非功能属性也是重要的决策因素。