The Dependency Inversion Principle

Depend on abstractions, not on concretions or High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. This is very closely related to the open closed principle we discussed earlier.

从面向对象OO方向出发，也是设计模式的思想有：

封装变化点

该原则的核心思想是，在程序设计中找出应用中可能需要变化之处，把它们独立出来以便以后可以轻易的改动或者扩充，而不影响不需要变化的部分, 哪儿变化就封装哪儿

面向接口编程

接口提供了非常优秀的抽象归纳，让我们的开发工作变得容易很多。一般实现一个系统的时候，通常是将定义与实现合为一体，不加分离的，认为最为理想的系统设计规范应是所有的定义与实现分离，尽管这可能对系统中的某些情况有点麻烦。

使用组合而不是继承

继承破坏封装性。基类的很多内部细节都是对派生类可见的，因此这种复用是“白箱复用”；如果基类的实现发生改变，那么派生类的实现也将随之改变。这样就导致了子类行为的不可预知性；从基类继承来的实现是无法在运行期动态改变的，因此降低了应用的灵活性。继承关系有很多缺点，如果合理使用组合则可以有效的避免这些缺点，使用组合关系将系统对变化的适应力从静态提升到动态，而且由于组合将已有对象组合到了新对象中，因此新对象可以调用已有对象的功能。由于组合关系中各个各个对象的内部实现是隐藏的，我们只能通过接口调用，因此我们完全可以在运行期用实现了同样接口的另外一个对象来代替原对象，从而灵活实现运行期的行为控制。而且使用合成关系有助于保持每个类的职责的单一性，这样类的层次体系以及类的规模都不太可能增长为不可控制的庞然大物。因此我们优先使用组合而不是继承。 当然这并不是说继承是不好的，我们可用的类总是不够丰富，而使用继承复用来创建一些实用的类将会不组合来的更快，因此在系统中合理的搭配使用继承和组合将会使你的系统强大而又牢固。

还有这些也很重要

Simplicity (KISS)

     The most important principle is keeping things simple. 简单是软件设计的目标，简单的代码占用时间少，漏洞少，并且易于修改。Simplicity should be your northern star, your compass, and your long-term commitment. Keeping software simple is difficult because it is inherently relative. There is no standardized measurement of simplicity, so when you judge what is simpler, you need to first ask yourself for whom and when. For example, is it simpler for you or for your clients? Is it simpler for you to do now or maintain in the future?

低耦合原则(Minimize Coupling)

       代码的任何一个部分应该减少对其他区域代码的依赖关系。尽量不要使用共享参数。低耦合往往是完美结构系统和优秀设计的标志

Designing for scale
     Designing for scale is a difficult art, and each technique described in this section comes with some costs. As an engineer, you need to make careful tradeoffs between endless scalability and the practicality of each solution. To make sure you do not over engineer by preparing for scale that you will never need, you should first carefully estimate the most realistic scalability needs of your system and design accordingly.
Design for Self-Healing
     The final design principle in this chapter is designing software for high availability and self-healing. A system is considered to be available as long as it performs its functions as expected from the client's perspective. It does not matter if the system is experiencing internal partial failure as long as it does not affect the behavior that clients depend on. In other words, you want to make your system appear as if all of its components were functioning perfectly even when things break and during maintenance times.
Designing For Failure
     Each application component must be deployed across redundant cloud components, ideally with minimal or no common points of failure
      Each application component must make no assumptions about the underlying infrastructure—it must be able to adapt to changes in the infrastructure without downtime
    &nb