其实做什么事情都是有逻辑结构， 包括软件设计。
目标
业务架构的第一个诉求是结构上是让代码清晰可表达， 对业务的发展符合开放封闭原则。其实所谓业务的开放封闭原则就是对于业务的发展应该既能满足现有功能需要， 而对于将来新增的需要只需要通过新增代码的方式就可以完成， 不需要从大的结构上修改现有的代码。 代码结构清晰可以自解释， 也大大降低了维护的成本。
业务架构的第二个诉求就是架构可以使得在开发过程中易于分工， 目前软件开发中很少单枪匹马的， 毕然是一个团队去开发， 所以在架构上保证各个功能易于分解， 减少并发开发时候的冲突，显得非常重要。
其实在软件领域中任何一个措施， 都是考虑成本， 效率， 收益的问题， 架构的本质也是从长远来看是降低陈本， 提高效率和收益， 包括之前推行的持续集成， 插件化，模块化复用，设计模式都是这个目的， 明白这一点， 做事情都直接可以用这个标尺衡量。
构想
功能和功能之间， 模块于模块之间毕然需要协作才能完成一些业务， 最终通过所有模块的写作去实现整个业务的需要。 所以标准化的消息结构往往是一个最通用的方法， 很多软件中往往利用一个消息中心， 所有涉及协作的事情， 都先发送一个通知到消息中心， 然后由中心广播分发给所有的协作者， 而只有感兴趣的协作者才需要处理这个消息。 这有点像将命令模式和监听者模式混合在一起。 如果将消息文本化或者序列号， 通过socket等远程方式序列化和反序列化报文， 可以实现本系统和外部系统之间的协作。类似windows等结构都是基于这个构想。
技术
这是一个很自然地构想， 对于面向对象的语言来说， 就是实现一个event消息中心就可以了， 有一个发送的代理， 一个链表结构保存所有协作者的引用， 然后每一个消息分发， 就是对协作者的轮询回调。
