我是一家大型金融公司的架构师，我们正开始在不同国家实施一个新的面向业务的信息系统。
从一开始，核心思想就是尽可能遵循面向微服务的原则(并确保工程师已经阅读了Sam Newman的《构建微服务》一书)。
现在我已经走到了十字路口。我们的服务主要是使用 Swagger 进行自动化文档的 JSON REST 服务，但为了在我们的业务流程中使用这些服务并确保不会将业务逻辑写入这些服务域之外的服务中，我们一直在使用 Camunda 作为编排工具。Camunda很好(尽管有些人认为Corezoid是一种替代方案)，但在一套优雅的服务中有些笨拙。
现在，服务编排是大多数工程师非常熟悉的概念。但这是我并不完全满意的，因为仍然有一个驱动一切的中央引擎。以后更换是非常昂贵的(尽管更换仍然比单体便宜)。即使这个中央引擎被分成多个引擎(今天实际上是这种情况)，它也不一定会让它变得更好。
近年来，微服务出现了一种向编排(接近事件驱动)架构发展的趋势。正是在这一点上，我正在向面临类似十字路口决策点的工程师和建筑师寻求建议。
我非常喜欢解耦架构的想法，尽管对杀死单体架构和拥有优雅的独立服务感觉良好，但我仍然在当前编排的解决方案中检测到业务流程中的许多依赖项，而这些依赖项实际上不应该存在。
这并不是说我们在回避事件。我们实际上也在我们的架构上实现了事件，以便将许多进程与核心原则解耦，即如果您不需要同步响应，只需要通知发生某些事情以启动另一个进程，则会放置一个事件，该事件可能会被另一个开始执行的进程捕获。编排更容易解释和可视化，更容易被更具技术头脑的业务用户调整和修改。而且我认为从业务角度进行测试和验证更容易。像这样的编排架构也(通常)期望良好的服务发现和高质量的自动化文档和非功能性需求，这些都是我非常重视的东西。
所有这些事情对我来说都是一个精心编排的问题，因为我没有大规模运行它的第一手经验 - 只是一些本地测试原型。
但我想你明白我来自哪里。我正在尝试考虑替代方案，而不必后悔最终将公司推向另一条路。
也许您可以分享自己在类似情况下的经验或分享一两个有趣的链接？还是我在寻找尚不存在的银弹？
服务需要交互 - 不交互的服务不属于同一系统。搜索需要访问目录，购物车无法从页面获取价格信息，帐户需要购买历史记录，推荐者需要购买历史记录，购物车需要验证当前可用的优惠券，库存需要知道已购买的东西等。
设置服务边界是为了最大程度地减少所需的交互。将服务削减为较小的组件是有意义的，但如果它们共享数据库(内部结构)，它们是服务的不同方面。
当服务交互时，它会创建一个级别的耦合 - 至少，这种耦合是服务必须"维护"的一些API(JSON或其他)，以便其他服务可以与之交互。
另一种耦合类型是时间耦合 - 这是您在请求-回复情况下得到的(您可以在事件驱动系统中消除) 然而，编排与编排不是关于这些差异(即使编排主要与请求/回复相关) - 它是关于中央控制和治理与灵活性和偶然性。
编排存在风险，例如将业务逻辑从服务迁移到编排中，而编排则存在混乱的风险。顺便说一下，直接请求/回复集成在两个世界中都是最糟糕的，但是当系统足够小时，它以简单性为赢。
在两者之间进行选择是一种平衡行为(就像大多数架构决策一样)，例如，Netflix 在编舞上构建了很长时间，但后来发现他们需要一些控制，并引入了编排引擎。没有什么是灵丹妙药:)
就我个人而言，我更喜欢编舞，因为减少了耦合和灵活性，并且更喜欢像开放式 Zipkin 这样的工具，为混乱带来一些秩序。
您可以在我所做的关于微服务的演示文稿的幻灯片 10-22 中看到基于业务流程的 arch 的部分示例
我想我明白你来自哪里，最近将系统重新设计为"微服务"架构。我喜欢(并使用)这些人的方法：http://scs-architecture.org/
重点是，您尽量避免"服务"之间的交叉依赖关系，这基本上使编舞过时了。困难的部分是将您的问题域分解为块，这些块对于任何执行的业务案例都不需要彼此。他们可能需要不同类型的数据，这些数据可能会或可能不会"共享"，就像在多个系统中一样，但他们不需要在任何给定业务案例中同步调用它们。
例如，这与Netflix正在做的事情完全不同。这些家伙/女孩正在通过不同的服务层进行链调用，每个服务层都将其逻辑添加到"流程"中。这种模式可能适合某些情况，也可能适合Netflix的情况。但这对你来说可能不是必需的。
理想的自包含系统将完全独立于其他自包含系统，将涵盖一个或多个高度内聚的业务功能(从UI到持久性！)，并且不会同步调用任何其他系统。理想的系统是让客户端"编排"，只需通过其Web(HTML)界面提供链接。
更像亚马逊。"登陆页面"是与"搜索"不同的应用程序，后者仍然与"结帐"不同。它们完全不同，有时甚至看起来有点不同！通过 HTML 中的链接和表单集成，而不是显式编排。
这可能就是您要找的。
一些警告：有些人的第一直觉是拥有"客户"微服务，或"产品存储库"微服务，以及类似的。这不会导致自包含系统，因为您需要对这些东西进行同步调用，使它们本质上是"中心"组件。关键是拆分业务域，因此边界上下文类似于埃里克·埃文斯。