微服务架构和脱离单体应用程序[关闭]

Question

我即将开始分解我们的遗留应用程序（构建在 EpiServer CMS 之上）。我们希望将其分解为更小、更易于管理的组件（微服务）。我倾向于 NServiceBus 和某种类型的域模型。有哪些工具可以帮助我？我从哪里开始？有什么可以帮助我识别不同的抽象点吗？

我知道这是一个有点宽泛的话题。然而，这是我负责的事情，任何反馈都会很棒。

Answer 1

一般来说，我建议不要在遗留应用程序上做这么多的工作，除非所有相关方都明白你正在做一个完整的重建。

问题是您要解决的问题是什么。报告工具的可维护性？提高部署速度？实现与其他系统的接口？解决一些性能问题？

一旦您确定了您要解决的问题，然后将其切割成有意义的小部分（对于微服务），然后您就可以开始定义您的域模型 (ddd)。例如，制作一个单独的报告服务来生成一些每周报告。然后尝试确定这是否真的解决了您的问题。将所有估算值加上 2 个月，然后检查企业是否仍然需要它。

如果是这种情况，请继续构建它，只需将部分 1 替换为 1。特别是如果您不知道从哪里开始，请不要使事情过于复杂。尝试解决业务存在的 1 个问题，并制作尽可能小的原型以表明可以交付功能。如果可能的话，您对需要进行的其他更改产生了一些善意。但不要决定使用 ddd 或微服务或 nservicebus 作为解决问题的工具。这些应该是对您要解决的问题进行分析后得出的结果。

更新2 当通信是一个大问题时，DDD 很棒。当存在复杂的业务领域时，或者当开发人员经常（稍微）误解业务需求时。

当您需要能够扩展时，微服务是一个很好的工具。当您想经常尝试新事物时，它也会有所帮助。不过，维护和调试您的事件可能会很痛苦。当你需要堆叠/聚合事件时要小心（如果事件 A 和 B 都在某个流程中引发，我需要 X 发生）

当您的应用程序的大部分可以异步发生时，Servicebusses 非常棒。一封需要在不久的将来发送的电子邮件，但不一定是这一微秒。文档生成、生成月度发票或处理传入请求（异步）。如果您需要等待事件的响应消息，那将是一件痛苦的事情。

UPDATE 并解决实际问题。不要添加太简单的东西并用它来引入服务总线（或其他很酷的技术 x）。如果您需要缩放，请解决实际需要缩放的问题。