很多公司的代码都是没有设计的，这种项目中所谓的“架构师”就是用最简单的3层结构，然后选一个框架实现IoC而已，项目基本没有自动化测试可言。如果项目已经开展好几年，也没人敢改了，一改就是大手术，改出问题还要担责任，只能越陷越深。。。。。。

设计原则： KISS原则 YAGNI原则 DRY原则 简单设计原则： 通过测试 消除重复 表达意图 让类和方法最小化 这些原则看起来都挺简单，但实际操作起来真的一点也不简单，对于大多数人来说所谓的过度设计其实是个伪命题，如果他能够过度设计至少说明他掌握了这些设计原则，但是我觉得真正理解这些设计原则的可能还是比较少

大道至简，知易行难，所以还是要多学习借鉴，多动手，还要有一定的悟性才行～

一直相信，架构是演进出来的，不可能有一蹴而就的银弹，这样的架构设计才能走的更远！

道理是知道，但实际上如何在新项目落地，在旧项目落地，都是一项巨大的挑战。

这一专栏，是我最喜欢的，我听了多遍，每一次都有新的感悟。

对于大多数人来说其实是没有设计。 在对业务不是特别熟悉的情况下，估计很难一上来就按照领域驱动设计的思路建立模型，做出优雅的设计。如果能够按照 DRY 原则，或者前面的 SOLID 原则，把代码重构的漂亮一点就很好了。 YAGNI 和奥卡姆剃刀原则有点类似，中文翻译更像，“如非必要，勿增功能”，“如无必要勿增实体”。 思考题说要列举一下设计原则，我觉的有这篇里面的 KISS、YAGNI 和 DRY，加上之前的 SOLID，似乎已经足够了。 在网上找了一下，有人补充了 CARP, Composite / Aggregate Reuse Principle 组合/聚合复用原则，“组合、聚合优于继承”；还有 LOD, Law of Demeter 迪米特法则（也叫做 LKP, Least Knowledge Principle 最小值是原则）。 迪米特法则和接口隔离原则比较接近，而组合/聚合复用原则就比较像里氏替换原则的实现。

不用焦虑过度设计，因为我们大多是没有设计的，还远远达不到，我想也只有先经历了过度设计，有了足够的积累，才能达到返璞归真——简单设计。

分离关注点最重要，不然就只能吃了不会解耦的亏。保持简单很重要，复杂的系统无法避免熵增，熵增只会带来混乱和灭亡。 设计得好就是正交分解，设计做得不好就是过度设计。 我之前也常说不要过度设计，可是连设计的知识都没掌握，怎么做设计都还不清晰，就去考虑过度设计，想想自己真是愚蠢噢。 还是得先全面学设计原则和实践案例，不要怕过度设计，不然怎么界定过度设计与简单设计都做不好，对人说起也没有说服力。