架构成长之路
产生软件架构设计的动机是代码复用，当一段重复的代码在多个不同的模块之中重复多次、每个人都为这段代码写的吐血的时候，大家自然而然就想到了——我们要有一个“架构”，或者说准确的说是一个框架。
最原始框架一定是最基本的。从广义上来说，操作系统就是一个框架，它封装了每一个程序需要完成的基本任务，管理内存、磁盘IO、中断、输入输出等。不过操作系统能封装的东西有限，最关键的是，封装总是略显简单。比如，需要写一系列服务器程序，每个程序都要访问网络、保持长连接、管理连接池等，这些机制并不是几行代码就可以实现，需要一个稍微高一点层次的框架来解决这个问题。于是很自然的，层次的概念就出来了。
当框架有了层次概念之后，大家就可以各司其职，为完善各自的框架而奋斗，直到最终框架已经极为好用，每写一个程序就像冲杯奶茶一样容易。大家都很高兴。
到现在为止，软件架构似乎还非常的简单直白，但随着时间发展，复杂的需求涌现出来了，架构也就突破原来软件框架的范畴，变成更复杂的东西。
还是拿那一系列服务器程序为例，假设它们是一个在线交易平台的后台服务。某个程序员完成了个人转账业务的代码，另一个程序员完成了商户转账业务的代码，互相一比对发现，嘿，大家怎么写的大同小异，应该优化。不过这样的优化存在着风险，因为谁都不能完全确定，未来这两个业务会怎么发展。
保守的程序员会让这两份代码独立，静观其变，反正框架已经足够好，重写一份这种业务也花不了多少时间。这并没有错，不过会错失让架构突破框架限制的机会。
喜欢挑战的程序员会仔细思考这两个业务逻辑，从业务的层面来分析其中的异同以及未来变化的趋势。
比如转账这件事，无论是个人业务还是商户业务，创建交易、记账这些事情总少不了吧，这或许可以抽象出来，但是检查账户权限、验证密码这些事情肯定会不一样，这些东西保持尽可能的可变。如此这般，业务层面的封装逐渐成形，所谓的架构终于有了架构的意思。
在引入业务之前，前面提到的“架构”只是一个放之四海皆可用的程序员的玩具；引入业务之后，架构终于得以走向成熟，摆脱程序员的束缚，反过来影响程序员的思维。
真正让架构腾飞的是引入领域知识（domain knowledge）的概念。作为一个具有业务功能的系统，要维护业务的纯正性不容易。还是拿转账来说事，如果提供了创建交易和记账的业务抽象，再假设转账是一气呵成的，从代码上来说，先创建交易还是先记账其实没有太大区别。但这事搁在包含了领域知识的架构里面可不行，因为账务要求，必须先有单据再有流水。
领域知识把程序员变成业务专家，渐渐的程序员就更能明白什么是业务、什么算框架，也可以开始用业务接口包装子系统，理解子系统之间的逻辑，让架构日臻完善。
P.S. 上面这些文字并没有涉及具体的设计原则、方法。
P.S.S. 再完美的架构也需要持续改进，况且这世界上恐怕还不存在所谓“完美”的架构。
分享/收藏
