SOA旅程:从了解业务到敏捷架构旅程:从了解业务到敏捷架构
识别服务边界的错误方法
在深入研究什么样才是良好的服务之前,请让我指出在定义它们的边界时最常遇到的错误方法。
实体服务
将一个系统拆分为实体服务是一种经常被用到的方法,它被称为反模式。有时候,这个方法源于对重用的痴迷:所有跟某个实
体相关的东西,要完全可重用,那是天赐良福!但是,在作为一个主要动机,代码重用其实是个悖论。我相信对于服务来说也
是一样的。
因此,以下是这种方法的缺点:
紧密耦合:每个服务都是其他服务的客户端。因此,如果有一项服务发生变化,你就必须测试整个系统。
通信频繁:它们有大量的内部通信,通常是同步的。这让系统变得脆弱,让速度变慢。
大量的服务:难以理解整体情况,也难以跟踪请求。
糟糕的封装:业务规则遍布整个系统。通常,每个客户端在更新其他服务的数据前要做一些检查。同时,更新是与更新查询一
起进行的,数据和行为被分开了。
同步:特别是基于http时,后面我会仔细讲讲它的缺点。
这是实体服务通常看起来的样子。
盲目将模糊的业务架构映射到技术架构
我常常遇到的一种方法是:“我们的任务就是要写代码交付产品,让我们开干吧!”好吧,对于小型项目,这是可以的,但是,
对大一点的项目就不可行。它不可避免地带来业务和IT之间的阻抗,从而导致业务敏捷性降低。并且,如果你不够敏捷,那么
你就出局了。
下面是与业务功能不一致的技术架构: