最近在做一个微信相关的项目。遇到一个情况是当用户关注我时候，需要存储用户信息（同样的需求会有很多，例如：用户预订一个产品，这个时候库存需要做相应变化。等等）。 用我们行内一句话就是：发布订阅。
如果代码直接写可能是这样的：
关注（）｛
//to do
createUser()
｝
createUser(){ // todo } 如果稍做重构，这两个方法可能不在同一个文件里面，需要引用一下。 即使这样，我感觉我们代码还是紧耦合。
所以我想到了 关注时候发布一个创建人的消息，让创建人的代码一直监听就行。如果有任何人发布消息，我自己去创建不就好了，什么代码做什么事。nodejs真是擅长做这种事情。
如果感觉陌生，看一下文档就这几个方法，真是简单啊。 https://nodejs.org/api/events.html
基本上是这样的：
emitter.listeners(event) 监听
emitter.emit(event[, arg1][, arg2][, …]) 发布
以下是我的代码： 创建event_emitter.js. (统一管理所有的事件监听)
var person = require(‘…/routes/a_person’);
var events = require(‘events’);
var emitter = new events.EventEmitter();
/*
创建用户事件监听
*/
emitter.on('create_person’, person.createPerson); // person.createPerson 是业务代码，创建人的代码。
module.exports = emitter;
在需要微信关注的代码中发布事件。
var emitter = require(‘…/routes/base_event’);
emitter.emit('create_person’,msg.fromUserName,function(){ });
ok，完成了。
看上去挺好，但是是不是逻辑性、可读性、可维护性都下来了？ 有一种情况你可以考虑用这种方式：当你的数个功能逻辑都需要用到同一种处理过程的时候，可以考虑，但是建议尽量还是定义和调用公共模块，使功能实现有完整的流程性和逻辑性，否则代码逻辑在不同文件中跳来跳去，会不会看了之后晕乎乎的？
谢谢 @zlbbq @lgyhitler 的回复。 感觉不错。下面是我的理解
从使用情况来看，代码在不同文件中跳来跳去，会晕晕乎乎的情况还好。
因为发布－订阅－业务逻辑。 代码固定在自己应该所在的位置，看起来还可以。
之所以采用这个方法，主要是两个不相关的实体，出现业务联系的时候，采用的。 如果业务紧密我感觉直接调用会更好。
比如：
适宜采用：订单生成时候，需要发消息给其他部门。
不适宜采用：订单和订单明细（主表和子表）的生成。
