Seneca是一个很有趣的工具，它的目的在于复制架构师和开发人员的服务想法，提供方法把代码融入到由模式所触发的逻辑行为中，这是根据用例所作用的模型。一旦被定义，模式就可以轻松转为API，使用用例和模式来定义消息内容。

随着模式实现为用例，他们还可以让我看到哪些地方需要添加业务逻辑。例如，如果你正在构建机票预订服务以及乘客细节模式的话，这时你很可能需要实现代码来处理频繁的飞行细节，并将它们添加到旅客机票记录中，以及记录机票号码和乘客的频繁使用的帐户。

开发人员把Seneca描述为“业务逻辑管理者”，对这一方法的最恰当描述是它提供了你所需要大量东西来构建一系列的微服务。Seneca 通过服务插件（常见的SQL和NoSQL数据库的实现）进行扩展，以及一些其它的Node.js模型，这样你就可以使用NPM（节点包管理器）安装的所有东西。它让你使用 Seneca来连接熟悉的中间件，简化把现有应用打破成不同服务的处理过程。

虽然使用Seneca和Node.js给你提供了一个轻量级的服务架构框架，但这只是一部分，因为你还需要考虑服务作为分布系统扩展的一部分。即，在实践中，你必须重新发明SOA这个轮子，并实现一些消息代理形式作为一种工具，向运行在容器中的Node.js 服务集群交付消息。其中一个有效的选择就是开源MQ实现，使用它在多个来源中提取消息，然后通过发布和订阅服务协议把它发送至 Node.js服务中。与自己编写扩展消息路由相比，这简单的多。

一旦你开始使用像Seneca这样的工具来构建微服务，然后你就要把它们构建到测试和部署的devops工作流中。构建和部署基于服务的应用程序都很好，但却无法维护，这一点很折磨人。你还要在服务周围实现一些 持续交付模型的形式，然后使用它来管理并发布更新——这是一个比编写代码理棘手的问题。

使用微服务构建现代化应用程序是很有意义的，因为它让你既利用了扩展横向扩展架构，也利用纵向扩展架构；还额外得到API的组合，且在整个业务中可重复利用。可能，每一分钟构都在交付新服务，如亚马逊那样，这样你就必须拥有一个敏捷的且响应的应用程序平台，这一平台一直在不断改进中。