微服务架构与脱离单体应用
Microservices architecture and breaking away from monolithic application
我即将开始分解我们的遗留应用程序（构建在 EpiServer CMS 之上）。我们希望将其分解为更小、更易于管理的组件（微服务）。我倾向于 NServiceBus 和某种类型的领域模型。有哪些工具可以帮助我？我从哪里开始？有什么可以帮助我识别不同的抽象点吗？
我知道这是一个比较宽泛的话题。然而，这是我负责的事情，任何反馈都会很好。
一般来说，我建议不要在遗留应用程序上做那么多工作，除非所有相关方都明白您正在进行全面重建。
问题在于您要解决的问题是什么。报告工具的可维护性？提高部署速度？实现与其他系统的接口？解决一些性能问题？
一旦你确定了你试图解决的问题，然后将它分解成有意义的小块（对于微服务），然后你就可以开始定义你的域模型（ddd）。例如，制作一个单独的报告服务来生成一些每周报告。然后尝试确定这是否真的能解决您的问题。在您的所有估算基础上增加 2 个月，并检查企业是否仍然需要它。
如果是这种情况，请继续并通过将零件 1 个替换 1 个来构建它。特别是如果您不知道从哪里开始，请不要使事情过于复杂。尝试解决业务存在的 1 个问题，并制作尽可能小的原型以表明可以交付该功能。如果可能的话，您会为需要进行的其他更改赢得一些善意。但不要决定使用 ddd 或微服务或 nservicebus 作为解决问题的工具。这些应该是对您要解决的问题进行分析后的结果。
更新2
当沟通成为一个大问题时，DDD 非常有用。当存在复杂的业务领域和/或当开发人员经常（稍微）误解业务需求时。
当您需要能够扩展时，微服务是一个很好的工具。当您想经常尝试新事物时，它也会有所帮助。不过，维护和调试您的事件可能会很痛苦。当你需要 stack/aggregate 事件时要小心（如果事件 A 和 B 在特定流程中都被引发，我需要 X 发生）
当应用程序的大部分可以异步发生时，服务总线非常有用。一封需要在不久的将来发送的电子邮件，但不一定是这一微秒。文档生成、生成月度发票或处理传入请求（异步）。如果您需要等待事件的响应消息，那将是一件痛苦的事情。
更新 并解决一个实际问题。不要添加太简单的东西并使用它来引入服务总线（或其他很酷的技术 x）。如果您需要缩放，请解决实际需要缩放的问题。
我即将开始分解我们的遗留应用程序（构建在 EpiServer CMS 之上）。我们希望将其分解为更小、更易于管理的组件（微服务）。我倾向于 NServiceBus 和某种类型的领域模型。有哪些工具可以帮助我？我从哪里开始？有什么可以帮助我识别不同的抽象点吗？
我知道这是一个比较宽泛的话题。然而，这是我负责的事情，任何反馈都会很好。
一般来说，我建议不要在遗留应用程序上做那么多工作，除非所有相关方都明白您正在进行全面重建。
问题在于您要解决的问题是什么。报告工具的可维护性？提高部署速度？实现与其他系统的接口？解决一些性能问题？
一旦你确定了你试图解决的问题，然后将它分解成有意义的小块（对于微服务），然后你就可以开始定义你的域模型（ddd）。例如，制作一个单独的报告服务来生成一些每周报告。然后尝试确定这是否真的能解决您的问题。在您的所有估算基础上增加 2 个月，并检查企业是否仍然需要它。
如果是这种情况，请继续并通过将零件 1 个替换 1 个来构建它。特别是如果您不知道从哪里开始，请不要使事情过于复杂。尝试解决业务存在的 1 个问题，并制作尽可能小的原型以表明可以交付该功能。如果可能的话，您会为需要进行的其他更改赢得一些善意。但不要决定使用 ddd 或微服务或 nservicebus 作为解决问题的工具。这些应该是对您要解决的问题进行分析后的结果。
更新2 当沟通成为一个大问题时，DDD 非常有用。当存在复杂的业务领域和/或当开发人员经常（稍微）误解业务需求时。
当您需要能够扩展时，微服务是一个很好的工具。当您想经常尝试新事物时，它也会有所帮助。不过，维护和调试您的事件可能会很痛苦。当你需要 stack/aggregate 事件时要小心（如果事件 A 和 B 在特定流程中都被引发，我需要 X 发生）
当应用程序的大部分可以异步发生时，服务总线非常有用。一封需要在不久的将来发送的电子邮件，但不一定是这一微秒。文档生成、生成月度发票或处理传入请求（异步）。如果您需要等待事件的响应消息，那将是一件痛苦的事情。
更新 并解决一个实际问题。不要添加太简单的东西并使用它来引入服务总线（或其他很酷的技术 x）。如果您需要缩放，请解决实际需要缩放的问题。