服务粒度设计原则与服务组合—兼谈应用软件的症结(二)
摘要：企业应用架构、企业技术架构 参阅：序 消灭人狼 软件的十大命题 编程规则
SOA、SOA、SOA！
现在许多企业都在进行基于SOA的应用治理,这里的关键是服务和架构,架构在上一篇<架构简述>中已经作了介绍,本文重点讨论服务粒度设计原则和服务组合。
困扰目前应用领域的主要问题是服务的粒度如何把控，服务如何组合使用？
先说服务粒度，服务该如何划分，粒度如何把握，这是系统的关键，目前应用领域在这方面没有标准和指导原则，造成系统混乱、死板，也是目前应用软件的主要症结，如果解决好这个问题，许多事情迎刃而解。
目前各应用系统最大的问题在于后台的服务实际上就是根据功能需求确定的（那些前后不分，没有清晰服务概念的系统不在讨论范围之内），一切以功能为导向的设计都是庸俗设计，当我们在这样面向功能的服务思路的影响下，服务粒度的划分就永远纠缠不清了，没有基于业务本质的抽象，都是面向具体易变的功能，这时讨论服务粒度都是毫无意义的，其实就是在围绕功能编写程序而已。
服务的划分和粒度应该建立在架构的基础上（参见下图），这才是SOA的精要，服务要划分为服务组件和基础服务组件两各层面，这是服务设计的关键！
服务组件实现的功能类似于面向功能的服务，但细节上完全不同，它不同于传统的服务直接操纵数据和处理业务逻辑，它不直接与数据层打交道，更不涉及具体的业务逻辑，它通过组合调用基础服务组件实现一个具体的业务功能。
基础服务组件不要面向功能，就是说它不关心是那个具体的业务功能在调用它，它面向业务领域的核心基础逻辑，负责与业务对象和数据层交互，因此也封装了该领域的数据。它的特征是稳定的，与数据层是紧密关联的，它与数据层一起构成应用系统稳定的核心和关键，其他部分包括服务组件和UI都是非关键和随时可以替换的。
服务组件粒度的设计原则
将服务拆分为服务组件和基础服务组件后，再谈论粒度就有了基础，首先服务组件的粒度不重要，按功能要求划分即可；基础服务组件的粒度才是设计的重点，这时基础服务组件的设计摆脱了功能的束缚，就容易界定了，高内聚、低耦合是宏观的指导原则，但不易把握，因此给出如下基本原则：
1） 独立和完整性原则。
保证一个基础服务组件业务概念的独立和完整，这是基础服务组件设计的最关键原则，一个基础服务组件完成业务领域某个完整、而独立的事项，它可以被多个服务组件共享使用，它做的事情既不多也不少，恰到好处。
2） 单一职责原则。
基础服务组件职责要单一，只做一件事，做好本职工作，不做分外之事；只有做到单一职责，才能提高基础服务的共享能力和稳定性。
3） 原子性原则。
基础服务组件应该具备不可再分的性质，也就是说如果将一个基础服务组件拆开，拆开的两部分将从来不会被独立使用，还必须联合使用，这就是基础服务组件的原子性；反之，如果一个基础服务组件可以被拆分为两或两个以上的组件，并且它们都可以被独立使用，说明该组件的职能不单一，不满足原子性原则，必须进一步拆分。
4） 数据相关性原则。
基础服务组件是对基础业务逻辑和数据的封装，它通常都会与数据层交互；如果不需要与数据层交互的组件，可以纳入到公共函数层，不作为服务组件管理，例如，账号合法性校验，计息模块等。
5） 相互操作性原则。
基础服务组件允许相互调用，可以使用共享公共库函数。
把握好上面的原则，就可以合理地确定基础服务组件的粒度了。
企业级应用系统架构图
服务组合
服务组合是一个更广泛的话题，涉及到架构的各个层面，单独讨论某一个具体层面都是片面的，从上面的图可以清晰地看到服务组合在三个层面都会发生：
1） UI层 -- 丰富
一个复杂用户界面可能会关联多个后台服务、文件服务、消息服务，可能会启动或参与一个业务流程，这是服务组合最灵活、最丰富多彩的层面。
2） 中台 -- 灵活
中台的服务统一接入通常表现为对服务请求的简单转发，服务组合则由流程平台或服务组合平台实现，它们通常表现为可视化的流程组织或服务过程脚本语言。
这一层面是按业务流程或过程对服务的组合，是系统实现对业务灵活性的关键设计。
3） 后台服务层 -- 细腻
服务组件实际上是对基础服务组件的过程组合，是面向功能的基础封装，我们虽然强调基础服务组件的重要性，但服务组件才是真正提供各系统使用的服务，也就是说从应用系统的角度看，服务组件是唯一可见的服务，基础服务组件被服务组件隔离和隐藏，服务组件是为了实现系统功能而对基础服务组件进行的最有效组合。
这一层的服务组合的特点是细腻和相对稳定，它虽然没有基础服务那样稳定，但相对于业务流程和UI层的组合而言还是相对稳定的。
参阅：http://blog.csdn.net/xabcdjon/article/details/6876058
http://blog.csdn.net/xabcdjon/article/details/6707050