看着将要落下的夕阳，感叹夕阳的美，我同时也多少产生了有点伤感。我也是已经快30了，到了而立之年，事业一事无成，多少对自己有些不满。在广州的IT软件行业转来转去，我当初选择该行业的初衷和激情都已经被一点一滴的磨光了。做软件最让我开心的应该是看到自己主导或者参与的产品给用户带来了实实在在的价值，解放劳动力，让用户喜欢上。我本着对软件研发这一创造类行业的喜欢，喜好把自己的想法完整的实现，不断地创新和改进。对于这个行业的喜爱让我一直走下去，偶尔出现困惑，但是还是一直坚持着。
关于软件的架构设计，毕业三四年的时候，喜欢看一些blog，和一些同行在群里争论那种设计方案最优美，那种最具拓展等，那个方式效率最好等。当时还会因为这些事情跟同事争吵，甚至跟领导闹情绪，因为当时一般只考虑技术层面的因素，觉得那种技术好，那种技术架构优美等，或许很多的程序员跟我一样，都经过追求完美的阶段。我觉得追求完美本身并没有什么问题，但是架构的设计本身要考虑的问题很多，包括所应用行业/运行环境/人员配置/维护成本等，甚至项目周期，项目风险等，这些都是一个优秀的架构师需要考虑的问题。技术本身没有贵贱，合适的技术用在合适的地方。我对这句话的理解也越来越深刻了，做项目目标性也更加强了，对于重大的抉择也更加的慎重了。
对于一些设计的原则，还是可以多多参考的，例如”面向接口编程”，“封装变化点”，“高内聚低耦合模块化”，“避免双向依赖”，“读写分离”等等，我对这些感触还是很深的，主要理解其思想，自然而然也就会在实际中应用上了。另外，是一些设计模式，针对23种设计模式，你究竟是不是所有都记住了，这并不重要，重要的是你要理解设计模式的优美所在，在哪种场合用到，《Header First 设计模式》里面的解释还是不错的，因为只有你了解了这些，你才可能在实际中去应用它。有人喜欢把设计模式当成一个模版来套用，让实际生活中的一些场景往模式上套用，在前期的学习中，这一点并不是完全不可取。然而，对于实际的项目情况来说，应该是借鉴设计模式的思想和解决方法，把它和现实进行融合，做到真正的架构美。
IOC/AOP，这一对名词，在现在的软件行业中，都已经成为了必修课。IOC，全称： Inverse of Control 控制反转，即在程序中，被调用类的选择控制权从调用它的类中移除，转交给第三方裁决。这个第三方一般指的是一些容器，例如Spring/Castle等。IOC另解，依赖注入（Dependency Injection），调用类对被调用类的依赖关系由第三方注入，以移除调用类对被调用类的引用。AOP， 面向切面编程(也叫面向方面)：Aspect Oriented Programming(AOP),是目前软件开发中的一个热点，也是Spring等大型应用框架中的一个重要内容。利用AOP可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高了开发的效率。AOP是OOP的延续，是（Aspect Oriented Programming）的缩写，意思是面向切面（方面）编程。主要的功能是：日志记录，性能统计，安全控制，事务处理，异常处理等等。主要的意图是：将日志记录，性能统计，安全控制，事务处理，异常处理等代码从业务逻辑代码中划分出来，通过对这些行为的分离，我们希望可以将它们独立到非指导业务逻辑的方法中，进而改 变这些行为的时候不影响业务逻辑的代码。其实这些都是设计原则和设计思想的体现，大家可以思考一些其中体现了那些设计思想和原则，也解决了那些设计模式解决的问题。
在业务应用软件的开发中，领域模型的分析设计（DDA/D）的重要性也是不言而喻的，它贯穿着整个软件的生命周期。“用户需求”不一定是以用户为中心去思考问题，应该是以行业的业务逻辑以及客观现实，我们设计领域模型时不能以用户为中心作为出发点去思考问题，不能老是想着用户会对系统做什么；而应该从一个客观的角度，根据用户需求挖掘出领域内的相关事物，思考这些事物的本质关联及其变化规律作为出发点去思考问题。这或许是领域模型分析设计中需要特别注意的，我觉得以用户为中心来思考领域模型的思维只是停留在需求的表面，而没有挖掘出真正的需求的本质；我们在做领域建模时需要努力挖掘用户需求的本质，这样才能真正实现用户需求。
呵呵，关于架构设计，就胡乱说这么多，下次我会就软件项目管理继续~~~。