设计模式本身无所谓好坏，根据你要解决的目标问题，选择适当的设计模式。
系统架构
在企业级软件开发中，架构第一重要。架构有缺陷，系统就存在硬伤。优秀的架构来自于优秀的设计。这一点毋庸置疑。
任何成功的软件，即使它没有明确地使用建模思想、架构方法，但在骨子里、潜意识中，大都具有良好的设计思想和架构。
只有写过好多好多代码以后，只有做过一些够份量的企业级项目之后，才可能对软件架构形成清晰的认识。很难想像一个连几行像样的代码都没有写过的人，对程序思想和架构却有着深刻的认识。这种人，十有八九属于纸上谈兵之辈。
我们时不时会看到这种情况，软件的设计也不算太差，但程序员要么不知道怎么写实现代码，要么是代码写得缺乏效率，或不够强健，甚至有时连“架构师”自己对此都一筹莫展。
我们也常常听到一些声音，不要太拘泥于语言（技术）细节了，要从大处着眼，要有大局观，架构怎么怎么重要，这些都是大实话。不过现实情况往往是，很多程序员不是太拘泥于语言（技术）细节了，而是对语言（技术）细节掌握得还远远不够。
书本知识的重要性毋庸置疑，但绝不要以为读了两本书，自己就成了牛气的架构师、设计师或者什么建模专家。
从前的软件开发埋头实践而缺乏必要的理论指导。现在越来越走向另外一个极端：设计文稿越来越图文并茂，琳琅满目，但开发出来的软件却比以前差很多。这种表面文章，意义何在？
数据库
大多数软件都要和数据库打交道，并非只有MIS类软件如此，数据库知识几乎是非掌握不可的，无非使用深度和广度有别而已。迄今为止，我编写的每一个项目软件，都要访问数据库，有一个程序甚至同时要跟两个数据库打交道（Oracle和SQL Server）。
如果你上过任何一门数据库基础理论方面的课，或认真看过任何一本数据库基础理论方面的书，或许都不必再买更多的（类似的）书。二十多年以来，关系式数据库理论之稳定，远远超过C++语言的稳定:)
