那些无法被分解的流程便用来创建带有一定颗粒度的组合服务。对于和设计面向服务架构有关的语句，你读过几回呢？对于严格的原子性定义你又了解多少呢？——在原子性状态下，是否无法进一步分解流程？我猜你对第一个问题的回答是“不计其数”，对第二个问题的答案是“基本不知道”本次专栏将会对原子性给出一个严格定义，并且描述基于原子流程集成之上服务的颗粒度。　

以下是关于原子性的严格定义：如果流程的每个输入都被用来创建一个或者多个流程输出，这时就会产生软件原子性。从数学角度下的定义已经有好长时间了，使用这个定义的其中一种方式就是利用输入创建一个矩阵行，输出作为列，并且用每一个输出标记输入，一个原子流程包含的全部单元必须带有标记。

　　尽管矩阵以一种极为简单的方式决定原子性，但是如果单单依靠这种方式，是不够的。在正确的分解以后，很容易为矩阵的每个单元标记。所以，尽管可以利用原子性来定义，但是这种方法还是有其心理和实际缺陷的，在一定程度上会限制其使用效率。

　　在20世纪80年代，Mike Adler通过颠倒矩阵解决了这个问题。Mike用矩阵建立了分解，而不是用其来检查分解。为了创建一个分解，Mike设计了一个专门在这个矩阵上工作的代数。

　　最近，我再次看了一下Mike的研究，发现人们对于原子性的定义没有原来那样严格了，但是在对颗粒性定义方面又遇到了新的难题。Mike的分解代数，用起来有些笨重，很难通过纸笔进行运算。因此，我决定重新设计这个代数，里面进行了一些加强，你可以在设计分解时随心所欲的使用它。在这个网站上你可以完成一个矩阵，这个矩阵会生成一个业务流程或者数据流图，该数据流图用来表示SOA中的一个服务。

　　我发现和设计数据流图相比，在设计矩阵时会产生一些额外收益。首先，它可以让非技术人员在设计流程中获取矩阵。熟悉自己工作的人通常能够决定一个矩阵单元是否是建立在一个既定输入之上的，无论这个输入是和输出同步发生的，还是在输出之前发生的。他们不必会读其中的内容。其次，它还可以帮助IT行业的人管理理解复杂性，因为你一次只能做出一个二元判定：在矩阵一个单元中，一个既定的输入会影响一个既定输出码。最后，人们会被一些暗示的分解搞得莫名其妙。我认为，作为设计者，我们通常只看到那些曾经为我们工作过的分解，往往忽视了其他的分解。

　　下面，我们要重新回到对原子性的定义上，我会使用那些从矩阵中得来的数据进行定义，这个矩阵采用了分解代数。

　　你可以在分解设计博客上查看到这个矩阵以及具体的演算细节。这里对定义做出了细致的视觉描述。该分解代数要保证图表中显示的所有流程都是原子性的。

　　要想创建图表中所显示的复合服务，必须决定业务流程中的原子任务采用了哪些外部流（或者其等效物）。为了更好的向大家展示，我们假设流程的顶端层与流程图表的不同任务相关联。每一个任务都变成了一种服务。和服务相比，图表中顶端层下共有的流程的实施效率更高。然而，经过一段时间以后，如果一个业务任务要访问更低一层的流程，此时的流程被看成是一种服务。那么这个流程就要被析出因数，作为服务。通过这个模式，服务拥有合适的颗粒度，完成业务流程图表。

　　这一技术为设计提供了原子性以及决定服务颗粒度的可视化方式。大部分方法都可以运用到设计当中，因为所有这些方法都暗示了一个分解，设计者可以选择使用或者不使用这种分解。我一直在想办法改进这一分解代数及其实施，并且我希望每一个访问我博客的人，都能对此作出回应，发表自己的观点和看法。