面向任务的体系结构(MOA)是比SOA更好的描述事物的方法吗？

Question

我可能听起来像个巨魔，但我想要更深入地理解这一点。我工作的地方已经开始使用MOA这个术语，而不是SOA，因为我们认为它更清晰，并希望将它与SOA的真正目标进行比较。

面向任务的体系结构是一种将应用程序分解为各种业务任务元素的方法，数据库、文件资产、批处理和实时功能在交付该功能方面都是紧密耦合的。该任务允许开发人员将精力集中在特定的功能上，以获得正确的功能，并能够将其构建为整个应用程序中的独立实体。通过紧密耦合数据、文件资产和业务逻辑，您可以实现处理一个非常大的问题的目标。

SOA的一些定义将其与web服务上的方法调用与真正的“服务”混合在一起。作为一名架构师，我一直觉得让每个人在SOA问题上保持一致是很有趣的。

把它称为“使命”与“服务”更好吗？

Answer 1

对我来说是个坏主意。

SOA的全部目的是围绕简单、可组合、松散耦合的服务设计架构，这些服务不仅可用于实现当前的“任务”，还可用于实现未来可能出现的“任务”(一如既往)。

如果你把每件事情紧密地结合在一个特定的“任务”上，那么你就回到了为每个应用程序构建一个新的、特定于项目的、可能是过度工程的、不兼容的软件栈的糟糕的旧方法。随着新需求的出现，您可能很快就会发现自己在它们之间创建了一个凌乱的点对点集成网络。

当然，拥有一个“使命”本身没有什么错--事实上，这是一种非常有用的方法，可以专注于真正创造价值的东西。但是，您不应该陷入围绕它构建应用程序体系结构的陷阱。

不要把SOA和"web服务“混淆起来。这是实现远程服务的一种方式，但是没有它们是完全有可能实现SOA的。例如，您可以使用JVM进程中的Java接口很好地实现松散耦合的服务模式。

Answer 2

不，我不认为您应该推动将术语从SOA更改为MOA。除非您相信您说服整个世界更新对SOA的所有引用。

你是对的，当你说人们一起工作时，必须使用被理解为对每个人来说都是同样的东西的术语。在你的脑海中，面向使命的建筑听起来是一个更好的选择，但当我读到这个问题时，我以为你在谈论发射火箭到月球的应用程序。显然，如果我要和你一起工作，你仍然不能假设我会对你已经拥有的术语有同样的解释。

SOA不是您的团队或公司想出的术语。如果您希望有人在SOA方面接受教育(不管它多么有趣)，您可以先让他们阅读外部链接：

• http://en.wikipedia.org/wiki/Service-oriented_建筑
• http://msdn.microsoft.com/en-us/library/bb833022.aspx

但如果有人加入你的团队，或者第三方公司与你合并，他们就会得到这样的结果：

• http://renewableplus.blogspot.com/2012/06/mission-oriented-architecture-moa.html (这是一个巧合，在页面上实际上有一张火箭的图片。这只是我在写完上面的文章后发现的最热门的谷歌点击数之一)