我是一家大型金融公司的架构师，我们正开始在不同国家实施一个新的面向业务的信息系统。
从一开始，核心思想就是尽可能遵循面向微服务的原则（并确保工程师已阅读 Sam Newman 撰写的《构建微服务》一书）.
现在我已经来到了十字路口。我们的服务主要是使用 Swagger 进行自动化文档编写的 JSON REST 服务，但为了在我们的业务流程中使用这些服务并确保不要将业务逻辑写入这些服务域之外的服务中，我们一直在使用 Camunda 作为编排工具。卡蒙达也很好（尽管有些人认为 Corezoid 作为替代方案），但在一套优雅的服务中却显得有些笨拙。
现在，服务编排是大多数工程师都非常熟悉的概念。但我对此并不完全满意，因为仍然有一个驱动一切的中央引擎。以后更换的费用非常昂贵（尽管更换仍然比单体更便宜）。而且即使这个中央引擎被分割成多个引擎（今天的实际情况就是这样），它并不一定会让事情变得更好。
近年来，出现了一场微服务走向精心设计的运动（接近事件驱动）建筑学。正是在这一点上，我正在向面临类似十字路口决策点的工程师和建筑师寻求建议。
我非常喜欢解耦架构的想法，尽管对消除单体并拥有优雅的独立服务感觉很好，但我仍然在当前精心策划的解决方案中检测到业务流程中的许多依赖项，而这些依赖项实际上不应该存在。
我们并不是在逃避事件。我们实际上也在我们的架构上实现了事件，以便将许多流程与核心原则解耦，即如果您不需要同步响应，而只需要通知发生的事情以启动另一个流程，则会发布一个事件，该事件可能是被另一个开始执行的进程捕获。而且编排更容易解释和可视化，更容易由更具技术头脑的业务用户进行调整和修改。而且我认为从业务角度更容易测试和验证。精心策划的架构也是如此（通常）期望良好的服务发现和高质量的自动化文档和非功能性需求，这些都是我非常看重的。
所有这些事情对我来说都是精心设计的方法中的一个问题，因为我没有大规模运行这个的第一手经验 - 只是一些本地测试原型。
但我想你知道我来自哪里。我正在尝试考虑其他选择，而不必后悔最终将公司推向另一条路。
也许您可以分享您自己在类似情况下的经历或分享一两个有趣的链接？或者我正在寻找尚不存在的灵丹妙药？
