读完.NET企业级应用架构设计其中几条心得觉得不错，联想到平时自己的经验确实有道理，于是记录下来，时刻提醒自己。
若想设计出好的软件，普通的设计原则就够了。你并不需要特别的设计模式，不过若某个问题恰好可以由某个模式解决，那么该模式将成为解决问题的捷径。时至今日，重复发明轮子，绝对不是什么好事。
模式并不一定是某个问题的终极解决方案，使用模式也不会让你的代码更好，或者执行速度更快。你更不可能冲到客户面前说：“看，我的产品使用了组合模式、一个领域模型、控制反转和策略模式等，因此这个绝对是个完美的软件。正确应用模式只能保证解决问题，对待模式要有一颗平常心，不要话费很大的力气去让设计符合某个模式。
经过了多年的面向对象设计，我们可以总结出一些软件设计中的心得体会。这些体会每天都在指导着我们，我们也在将这些体会不断地传播给别人。
- 将逻辑相关的职责分组并组成类型。在分组的过程中，要特别留意组成有明确用途的类型。
- 为类型中的功能创建简洁灵活的抽象。在这个过程中，两个形容词能说明良好抽象的特征：清爽的和有弹性的。
- 在实现具体类型时，注意分离关注点——即谁应该做什么，并确保每个角色都仅有一个类型来扮演，且每个类型仅完成最少的工作。这样做并不是因为懒惰，而是因为力图简单和高效。
对于简单，无论怎样强调都不过分。尽可能保证简单，但不要再继续简单下去了。这是爱因斯坦曾经说过的一句话，每个软件从业人员都应该牢记于心。
简单是一切之本，这句话也叫做Keep It Simple，Stupid，这个理念出现在很多原则以及软件设计文章中。比较流行的原则有如下几条。
- 不要重复你自己：指降低应用程序中的重复，且建议对于同样的信息，仅在一个位置存放。
- 一次且仅一次：指降低同一个应用程序中编写同样代码次数。
- 你不会用到它：指仅当不可避免需要且没有其他解决办法时，再向程序中添加功能。
我们经常喜欢将“简单是一切之本”这个概念与人们在法庭上的权利相比：你所写下的所有东西都将成为调试过程中的障碍。不仅如此，这些东西也会用在每次你与客户之间的会议上，且对你不利
软件可以正常工作的概率与其所需要的代码行数成反比。
Bug出现的几率与正在查看该软件的人数及这些人的重要程度成正比。
专家就是那些最后一刻赶到，陪众人一起挨骂的人。