基础服务和复合服务的区别？

Question

最近在搞SOA，技术层面的东西还容易理解，但是思想层面的就相对有些难以消化了~

基础服务和复合服务，字面上来看非常简单，无非就是基础服务表示原子不可分，复合服务可以由多个基础服务或复合服务组合而成。

但是在实际项目中，往往很难容易的把业务场景归类为它们之中的某一个~

所以想问大家，有没有什么辅助分类的心得或原则？

希望以实际场景为例，我试着假设一种场景：

班级，学生

基础服务就是：

• 班级的基本信息的增删改查
• 学生的基本信息的增删改查

能否以此实例来延伸举一些基础服务和复合服务的实际例子？

Answer 1

SOA设计最好以实际例子来，以班级学生的增删改查做为SOA的例子，容易让人偏离SOA的目标。为了分布式而分布式。
SOA服务的抽象应该是最难的，不熟悉业务的肯定抽象不出来，所谓“增删改查”原子接口粒度太细了
以电商场景为例
增加一个订单，在之前要检查库存、检查用户帐户余额，生成订单、生成货品子单、生成支付单，不同的情况还有不同的分支，这里涉及到十几张表的逻辑，你要是提供一堆表的增删改查接口，客户端没法用，理解业务成本太高。
而且，稍微增加一个业务需求，比如下单的时候计算促销扣减，这个如果不封装到SOA接口中，就会散落到各个客户端去，这样SOA就没有任何意义了。
所以，SOA必然是带有业务含义、逻辑的接口，万万不能因为所谓的“原子性、重用性”，把以前一个进程内的数据增删改查接口发布成为SOA接口。增删改查的原子接口直接在进程内部搞定，不要发布成分布式的，否则效率太低了。

复合型SOA接口怎么抽象才能好，和你对业务了解的深度有关，这个看经验了，没有通用范式可遵循
如果是不理解的新业务，我们设计接口刚开始是遵循业务的需求，怎么方便怎么来。
一旦业务需求发生变化，或者多个业务需要使用接口，就会通过版本号迭代，接口重构，慢慢的把重用性做出来。
打个比方，刚开始我们用户中心有三类客户，分别在三张不同表，提供了三类不同的SOA接口，后来内部设计将其统一为主表+扩展表的形式，变为同一个表的用户不同的分类，这时候，就开始重构接口，设计2.0，将其统一。接口升级的时候，保持对前一个版本的兼容，也是很重要的。

Answer 2

是否可以以事务的维度去区分呢？

比方说，需要跨事务来完成的一些操作就属于复合服务？

Answer 3

那复合服务就是：

• 班级调整，增班并班之类的

---

没做过SOA，根据你的场景推的……