摘要:
最近在抽出时间做一个数据库的driver, 其中有些问题驱动的软件代码的思考，是很值得回味的。
做的系统，所思考的问题，所设计的解决方案，其实都是可以看作是对解决问题方式。而不仅仅是某个类库的API的使用，某个算法的实现复杂度，某个固定的设计模式，或者设计规约。
程序设计的思考:
- 对于技术的设计方案来说，某个业务领域的知识是一回事，比如说关系型数据库，时序类型的数据库，所要处理的业务，也就是DDD所谓的领域知识专家。
- 站在架构师的角度，是要从技术的角度，确保项目的成功，无论是功能性的需求，还是非功能行动需求，也就是性能需求，稳定性需求，甚至包括部署运维以及升级的需求，在不同的抽象层次的边界上，进行设计。
- 软件分成不同的抽象层次，在不同的抽象层次上，处理不同的问题范围。
- 而对于所谓的架构，从名词的角度，是一些功能点的组织方式，从动词的角度，是不同的功能的互相交互，达成一个完整的目标。但是无论是名词还是动词，都是与结构有关。
- 那么所要面临的是什么问题呢？从宏观的角度，是功能的分解，分解成更小的可以理解的部分，组成最小的功能单元。这个功能单元里，处理好本模块所能考虑到的所有的问题。
- 其实从这个角度上来说，比较适合采用思维导图的方式，而且是右向思维导图的方式，将功能层层分解，并且也将问题层层分解。
- 所谓的架构师，所谓的解决方案架构师，考验一个软件开发者的能力，便是他能驾驭多大的项目，保证这个项目的功能和非功能的要求。
- 结合业务，又从业务中抽离，要站在更高的抽象层次上做思考。抽象出通用的解决问题的思路，解决问题的办法。