SOA灵活架构分析与设计

    我曾经把关于业务开发平台与SOA统一论的观点发到QQ群中，但是遭到了现在很多正在研究SOA+ESB+BPEL众人的群殴：“神仙大师，你能不能从云中下凡一下，给我们讲讲怎么做才能不把SOA做死。别神叨未来，我们正靠ESB开发吃饭呢，未来爱谁谁，那是上帝都控制不了的，但是眼下开发SOA，偶是要做出来拿工资的。”。

    嗯，一下子给大家扔了一个共产主义，还得给大家说叨说叨SOA处于中国特色的社会主义阶段该怎么办？

    因为，有些朋友已经用SOA框架开发了。我在这里也就不给大家普及为啥世界上呼哧呼哧的都要SOA组件模型，为啥WebService不行。关于这个普及大家可以看我以前的文章。一句话：你为什么用面向对象。那么你也就能理解为啥不用webService而改用SOA模型体系。

    既然SOA只是一个组件模型体系，那么就好对比了。想必很多朋友都用EJB或者COM+开发过。大家可以扪心自问：我们开发的这些组件，真的在现实客户落地时候带来了灵活、快捷么？真的如我们想象N个小球，让我们来串一串，串一个幸运草串一个同心圆？

    我想，很多朋友们都摇头。

    根源就在于我们听客户说的，客户的描述是是用嘴一句句话说出来的，这是天然的流状。人的思维也是天然的流状。而项目经理从客户需求直接照搬映射到了软件功能。但软件内部设计谁在做？

    注意，软件内部设计，不是指软件业务功能设计，也不是指数据库建什么表什么字段，也不是指代码结构怎么个设计模式怎么个泛型。我说的软件内部设计，简单来说就是A+B。A是谁，B是谁，+号是谁？A+B就等于项目经理所说的软件业务功能设计。

    这里就有差异着，就不是客户需求直观影射到软件业务功能。这是一个思维重组。横看成岭侧成峰，就是这种力度。这个软件内部设计的人，就既要看到业务功能这个岭，也要看到A+B这个峰。就如同，鸟巢在我们眼里是一个奇怪艺术的大体育场馆，而在建筑工程师的眼里，就是物理学、工程学、建筑学，眼及鸟巢，心想的是水泥钢筋结构。

    我昨天也说过一种思路，就是有人看世间各行业务，都是组织结构、岗位权限职责、过程表单、查询列表、统计报表。于是，按照这种思维哲学设计出来的就是这样的业务开发平台。我们常见的就是这类哲学。

    我昨天还说过一种思路，就是业务流BPM、工作流WORKFLOW、业务程序控制流BPEL三流合一。但这个方法论的统一，我现在也没有想清楚。个人觉得应该是一件事物的三个层次或三个面，但这个统一的哲学，现在还没有出现。N多人想试试，但就是在产品中统一不起来，这都是方法论体系没有，产品根本无法统一落地。

    另外我说的一种另辟蹊径的就是，索性这些都别想了，facebook插件方式就能达到目标。反正都是为了解决同样的问题目标，所以用什么手段是自由的，干吗非要在一个方法论上钻牛角尖。作坊出来的人都这个思考方式，像李云龙。而IBM巨头之类，肯定是奔着方法论去了。企业级和草根，JAVA、.NET、PHP，就是三个不同世界观形成的产品特征和产品发展策略。

    但今天咱们扔开业务开发平台、扔开BPM、扔开facebook插件，咱们再回到根上想问题。

    过去我曾经说过，从大流水代码到函数、从函数到面向对象，从面向对象到面向组件、从组件进化到SOA组件模型。

    所以，核心还是SOA组件是关键。这就是我们要的小球，这就是DNA，于是才有道生一、一生二、二生三、三生千千万。

    客户絮絮叨叨说出来的需求，被项目经理映射成了输入表单、查询、输出统计报表、权限、处理流程。而我们要的是DNA，而表单、统计报表、流程，都不是DNA。因为他们一个上面都集成了多类DNA。实在不能这样看问题。所以昨天我也说，这样想都错了。

    我们需要从客户口中叙述的流状信息中把输入表单、查询、输出统计报表、权限、处理流程中间的DNA提取出来。有人曾经告诉过我一个土方法，就是把需求中的名词挑出来，这就是实体。把动词挑出来，这就是实体的操作。然后把客户描述的处理流程当作连词，就是为了把各个名词和依附于名词的动词串联在一起。

    我们的函数能一层层嵌套，那么我们的组件粒度也可以层层嵌套，粗，粗到一定级别，大家都有常识，很多人说把握不了组件的粒度，我说你就照你能想到的粒度设计，如果觉得太麻烦了，说明设计细了，需要包装一层。如果觉得还需要嵌套才能描述清楚，说明设计太粗了。就如同我们不会贴到电视屏幕前看电视，我们也不会离电视1公里，我们自己去设计的时候都有一个感官。软件开发本来就是一个艺术与技术结合的工作，没有定论，是随着团队的能力而变化的。不过，有一个小窍门。如果每个函数行数不能大于一个屏幕（不能滚屏），而一个业务处理需要嵌套超过三层了，就说明这个设计需要分解一下。三是个奇妙的数字，这是个常人在脑中掌控和理解信息能力的一个阀值。所以我们就这样做个土办法。有时候，从常规理解得出的方法，往往比科学家左算右算这模型那算法出来的更实用和直接，就好像前段时间我看的那个临时工和博士对处理肥皂厂空盒子问题的处理笑话一样。

    这个方法很山寨。但你仔细想想UML的用例图、包图、类图、交互图、序列图，也很有神似。UML是软件设计阶段的表现方法论。从软件设计这个岗位，用各种图来看用户业务（用例图），看整体结构（结构图）、看实现方法（包图、类图、对象图、交互图、序列图），看具体实现（活动图、状态图），看具体部署（部署图）。

    MDA，模型驱动架构。IBM、HP这些带头大哥，在N年前就推动的MOF、UML、ECLIPSE、JAVA、CORBA、RUP，就是希望从业务理解哲学、软件设计哲学、软件实现哲学、软件运行哲学、软件开发管理哲学统一。但至今磕磕碰碰。想创造完美世界，恰恰是一种不完美。就如同人类想建造通天塔一般。

    我也一直在用山寨路线思考着自己的业务哲学、软件分析与设计哲学、软件实现哲学、软件运行哲学、软件开发过程管理哲学。希望能浑然一体。我也在不断抬头看着远处的圣峰（MOF、UML、CORBA、RUP），对比着行进路线的差异和方向感。

    有中国特色的社会主义，我们确实需要这样特色的经过。

    山寨方法，可能会消失在历史的尘埃中，但中国软件业自己的行进方法，从无到有，从有到精，确实需要这个“有”字。

    我们现在要么大量IT企业什么都没有，要么极个别IT企业借助政府和资本的力量直接上了圣峰。这个“有”字确实珍贵。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友