在技术领域，常常提到的设计模式，完整的说是“软件设计模式”，要增加一个限定词，给出一个限定集才可能通过归纳法进行抽象，找到好的“模式/模型”，来指导我们做软件设计。这里还有一个隐形的问题需要讨论到，就是“这个模式要指导我们设计出什么样子的软件？”， 简单来说就是模式帮助我们设计出高质量软件，所谓高质量，就是能在整个软件生命周期过程中都尽可能的表现好，比如开发阶段效率高、迭代中扩展性好、交接中认知复杂度低、生产中安全稳定、运维时简单便捷等等。学习前人总结的经验/模式，就可以减少或避免自己踏入可预见的坑里。
既然设计模式是前辈们在开发软件过程中踩了大量的坑总结出来的，那回顾一下这个踩坑过程我想是有助于我们的理解和学习的，因为无序、无逻辑的学习效率是非常低的，通过回顾帮助大家把模式组织起来。
- 面向过程编程时代：我是从面向过程的语言QBasic和C语言学起来的，面对大型项目时，代码管理会变得异常困难。这时候，代码往往以无序的函数堆砌而成，给开发和维护带来了巨大的挑战，是软件系统管理的主要矛盾。
- 面向对象编程的兴起：为了更好地组织代码，面向对象编程（OOP）模式应运而生。它通过将函数和数据封装到对象中，将无序的代码组织成结构化的形式，极大地提高了代码的可管理性。
- 分层设计与MVC模式：随着类的增加，如何有效管理这些类成为了新的主要矛盾和挑战。分层设计模式随之出现，通过功能来组织类。MVC（Model-View-Controller）模式为分层设计提供了一个明确的框架。
- M层的细分：实践中发现，MVC模式下的Model层过于复杂，需要进一步拆分。这导致了Service层和Data或Repository层的产生，以实现更细致的分层管理。可以参见这里
- 领域驱动设计（DDD） ：随着系统复杂性的增加，层内类的组织成为了新的主要矛盾点。DDD(Domain Driven Design)应用了生物学的分类法（域(Domain)、界（Kingdom）、门（Phylum）、纲（Class）、目（Order）、科（Family）、属（Genus）、种（Species））来帮助工程师进行类的设计，核心在于如何定义和划分Domain。这不仅仅是业务分类的组织管理，更是一种对业务深入理解（过去、现在和未来发展趋势）和抽象的方法。以为DDD是简单的按业务划分类的组织和管理，其实是对DDD项目最表象的一层的直观的观察认识，DDD强调的是对业务的理解、统一语言定义和抽象实体的方法。
通过回顾设计模式的发展历程，我们不应该停留在知道这些模式和这些模式诞生的目标，更应该注意到的是：设计模式并不是一成不变的。它们会随着技术的发展和项目需求的变化而演进，是一个结合实际情况的应用过程，强调这一点是非常有助于我们理解设计模式的，学会灵活变化应用的同时不要强搬硬套。
设计模式的继续展开，才是大家常见常说的单例模式、工厂模式、消费者模式、装饰模式之类的。在继续展开之前，还有一些常被提到的总结的原则也比较关键，比如单一职责原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则等，这些原则是基础设计模式的设计思路的基础，会在各个具体的设计模式中看到这些原则的影子。
搜了一下Wiki，发现其总结的很好，就不废这事自己写了。请大家参考Wiki的这个表格学习。
通过读书或上边Wiki概况性了解这些设计模式之后，最后再聊一下如何深入训练和实践经验积累。一个是在真实项目中，能尝试的各种设计模式就强行尝试一下，试错成本很低，无非是浪费一些时间，踩一些坑，踩的这些坑也是加深理解和经验积累的必然过程。另外一个就是针对特定的设计模式自己设计一些实验项目，动手试一试，并设想迭代中可能发生的变化和问题。这两种实践过程中注意归纳总结问题，然后前辈咨询或技术圈子里做分享沟通，是提升的关键路径，不要闭门造车。最后有了一定实践经验积累后，反过来再读一些资深专家深入思考的书，如《软件设计哲学》等，与科普类的书不同，是思考类的书，此事你才会有不一样的感悟。
#今日份十分钟#希望通过回顾设计模式的发展过程帮助大家理解和学习。
