SpringBoy的博客

客户端不应被强迫依赖于其不使用的方法。这句话的意思是指尽量缩小接口的范围，使得客户端的类不必实现其不需要的行为。根据接口隔离原则，你必须将“臃肿”的方法拆分为多个颗粒度更小的具体方法。客户端必须仅实现其实际需要的方法。否则，对于“臃肿”接口的修改可能会导致程序出错，即使客户端根本没有使用修改后的方法。阿里云，华为云等云服务厂商都有自己不同的sdk实现，当同时使用多家云服务厂商时，就需要分别调用不同的sdk。假如我们现在想要封装出一套云服务厂商通用接口，可以定义接口，不同的云厂商分别实现即可。但是接口定义的

分析模型仅仅是理解工具，分析中也有一些知识消化的过程，但编码后，程序设计人员不得不重新进行抽象，这会导致领域知识丢失。用户会奇怪文件名是指什么。人们经常说技术水平较高的架构师负责设计，技术水平相对低的开发人员负责实现代码，这是错误的，因为软件开发就是设计。很多项目设计之初只考虑到模型如何设计，没有将模型如何实现、数据关系如何存储这些实现考虑在内，往往设计“很完美”的模型交给开发人员却无法落地。虽然项目初期设计了领域模型，但是模型没有与实现绑定，不能帮助开发可运行的软件，这种纸上谈兵的模型是没有意义的。

这时候可以先根据现有的知识形成初步的模型，后期通过对领域的逐步加深，逐渐细化设计后，要对原先不合理的模块、类进行必要的重构，使得模型与实现一致。团队内从需求描述、功能设计分解、验收用例设计等等都应使用通用语言交流，同一领域的相同词汇不应该反映不同的模型。使用UML图（主要是类图和对象图）进行软件设计讨论，此时的图应该着重表述模型的重要概念，可以选择性的忽略细节。对话是改善建模的最佳方式之一，试着大声说出模型变化的各种结构，这样不完善的地方很容被听出来。灵活的、知识丰富的设计需要一种通用的、共享的语言。

这一步在目前公司内推行还是有一定压力的，通常团队各个人员各为己战，产品只觉得把产品规划做好就行了，实现是开发人员的事情。而且，对设计所花的时间在整个开发过程中是相对较短的。所以这需要一些好的沟通方式或者沟通技巧，比如可以设计一个初步模型，有些备选方案，然后组织团队成员去讨论，提高效率。优秀的码农会自然而然的开发出一个具有可扩展的抽象模型，在团队成员一起消化理解模型的过程中，他们的交互也会发生变化。建立领域模型是团队成员将现实利用通用语言描绘的过程，有点类似于消化现实中的知识，转化为一种通用语言的模型。

现实中软件遇到的一些复杂性问题，人们更习惯通过使用一些技巧、框架去解决，而不会过多思考软件设计层面的问题。这其实把软件设计问题抛给了第三方框架去解决，或者只是规避了问题，很难去下手做出根本改变。**领域模型：**用于描述应用软件涉及领域的通用语言。领域驱动设计已经形成了一套软件设计的科学方法论，在软件开发活动中灵活运用才是事半功倍的方法。**领域：**应用软件的问题区域，如会计程序的金融领域，票务预订程序的乘客、余票等。其实软件遇到的复杂性问题很多是设计、架构不合理导致的。

单例模式的作用单例模式是Java设计模式中最简单的设计默认之一，其主要作用是用于维护全局单一示例对象。确保只有一个实例对象单例类自行实例化无论从单例类获取多少次，单例类都只向系统提供这单个实例。...