http://rekarupa.net/zhichang/208/

让我们给这个游戏加个进度条”)、可视化和生成报告(“为什么业

  我们之前曾经在muCon London2017(幻灯片录像)、OReilly Software Architecture London幻灯片录像)以及KanDDDinsky幻灯片录像)上颁发了讲话,展现了我们从头审视的成果。

  这些东西答应你利用ISO尺度的BPMN来以画图的形式定义流程,也能够利用其它流程言语来定义流程。这些流程言语凡是基于JSON、YAML或者依赖DSL(范畴公用言语)的言语(例如Java或者Golang)。一个主要的方面是,流程是高效地通过源代码定义的,因而它们能够间接被施行。施行意味着,形态机晓得若何从一种形态改变到别的一种形态。

  如许是没有问题的。然而,问题是没有任何一个办事清晰全局环境,令这个流程难以理解,更主要的是,难以改变。别的,你要记住,现实环境下的流程不会是那么简单的,凡是会涉及更多的办事。我们已经见到过一些微办事的使用导致呈现这种环境:一个包含很多办事的复杂系统做了某些工作,可是没有人真正地清晰具体做了什么以及怎样做的。

  在上面的示例中,工作流实例需要在一个特定的超时事务触发前期待一个商品收货事务。若是发生了超时,营业事务就需要弥补,意味着所有的弥补勾当都要被施行,并且在这种环境下付款会被退还给客户。形态机遇跟踪曾经施行过的勾当,因而可以或许触发所有需要的弥补动作。这答应形态机来协调营业事务,其根基理念也被称为Saga模式。

  我们假设,若是一项产物有现货并且能够顿时交货,结账办事该当给用户反馈。结账办事能够利用请求/响应的体例来向库存办事扣问存货的数量,可是如许就将结账办事与库存办事(在可用性、响应时间等方面)耦合起来了。

  工作流引擎是令人疾苦的(这也许看起来毫无联系关系,可是我们稍后会展现其联系关系关系)

  一旦团队起头利用事务驱动架构,他们凡是会对事务入迷,由于事务供给了惊人的解耦能力,那么让我们为所有营业都利用事务驱动架构吧!当你实现点到点的事务流,就像通过点到点的事务链实现订单流程,问题就会起头浮现。假设一个相当小的流程,它的实现体例是,办事链中的下流办事总会晓得它需要在什么时候做什么工作。