我即将开始分解我们的遗留应用程序（构建在EpiServer CMS之上）。我们希望将其分解为更小，更易于管理的组件（微服务）。我倾向于NServiceBus和某种类型的域模型。什么工具可以帮助我？我从哪里开始？有什么能帮助我识别不同的抽象点吗？
我理解这是一个有点宽泛的话题。然而，这是我一直负责的事情，任何反馈都会很棒。
答案 0 :(得分：3)
一般来说，我建议不要在遗留应用程序上做那么多工作，除非所有参与方都明白你正在进行一次完整的重建。
问题是你要解决的问题是什么。报告工具的可维护性？提高部署速度？实现与其他系统的接口？解决一些性能问题？
一旦确定了您要解决的问题，请将其剪切为有意义的小块（对于微服务），然后您就可以开始定义域模型（ddd）。例如，创建单独的报告服务以生成一些每周报告。然后尝试确定这是否真的解决了你的问题。为您的所有估算增加2个月，并检查业务是否仍然需要它。
如果情况确实如此，只需将第1件更换为1即可构建它。特别是如果您不知道从哪里开始，请不要过于复杂。尝试解决业务所具有的1个问题，并制作尽可能小的原型，以显示该功能可以交付。如果可能的话，你可能会对自己需要做的其他改变有一些善意。但是，不要决定使用ddd或微服务或nservicebus作为解决问题的工具。在分析您要解决的问题后，这些应该是一个结果。
<强> UPDATE2 当沟通是一个大问题时，DDD很棒。当存在复杂的业务领域时，或者当开发人员经常（略微）误解业务需求时。
当您需要能够扩展时，微服务是一个很好的工具。当你想经常尝试新事物时，它也会有所帮助。尽管如此，维护和调试您的事件可能会非常痛苦。当你需要堆叠/聚合事件时要小心（如果事件A和B都在某个流程中被引发，我需要X发生）
当您的大部分应用程序异步发生时，Servicebus是很棒的。需要在不久的将来某个时间发送的电子邮件，但不一定是微秒。文档生成，生成月度发票或处理收到请求（异步）。如果您需要等待事件的响应消息，那将是一种痛苦。
更新并解决实际问题。不要添加太简单的东西，并用它来引入服务总线（或其他酷技术x）。如果需要缩放，则解决实际需要缩放的问题。