《孤尽班T31-01-架构理论笔记》

孤尽，阿里巴巴技术大拿，开课吧CTO

---

当初得知孤尽大大会组建一个“Java学习班”的 时候，就期待能够加入其中，学一些“够牛B”的技术，从最开始的差不多600人，到最后的不到60人，留下的人大概为最初人数的1/10。这次我希望自己能够成为最终“毕业班”中的一员。我想再过一个月，等到第一期“T31孤尽班”毕业的时候，我想人数和现在的人数应该相差不大了，留下的人，或许技术不是最好的，但一定是有耐心有恒心人，坚持，再坚持，不仅对学习是这样，对生活、对梦想更是要这样坚持。

有些内容是整合补充资料，如有错误欢迎批评指正~

目录

架构理论心得

一． 需求分析

二． 架构设计原则

1. KISS 原则

2. DRY 原则

三． 设计原则

1.   单一原则

2.   里氏替换原则

3.   接口隔离原则

4.   组合复用原则

5.   依赖倒置原则

6.   迪米特原则

7.   开闭原则

四． 什么是“架构”

 五、架构图分类

一、应用架构（平台架构）

二、技术架构

三、系统架构

四、业务架构（产品架构）

---

---

架构理论心得

在进行架构设计之前，首先需要进行需求分析，从而通过所获取的需求条件进行架构设计。

什么是架构？
                一种能力的体现，而不是一个职位的设定。

                架构 = 组成 + 决策。

                组成 = 模块结构 + 模块关系。

                决策 = 约束 + 设计原则 + 演化方向。
                                                                                 ----孤尽 《阿里巴巴Java开发手册作者》

一． 需求分析

理解和挖掘用户诉求以及背后逻辑，从而转化成可行性的分析结果。

分析需求背后的人性，从需求的边界，用户故事以及用户路径对需求进行深入解析与理解。

需求落地路径：需求分析->可行性分析->设计->编码->测试->发布

二． 架构设计原则

1. KISS 原则

Keep It Simple and Smile

架构理念是大道至简以及要具有足够的协调能力，所以要考虑的点为：

• 系统可拓展可维护
• 系统能够恰当解决问题
• 系统运行时间足够长而不重构
• 能够处理好其他部门产生的挑战

如何在工作中实践KISS原则

• 先解决问题，再考虑编码。先将问题拆分的足够小，再动手编码完成这些功能
• 尽量缩短每个方法，它只要负责解决一个问题就足够了。每个方法的代码最多不要超过30-40行。
• 如果在方法中需要兼容很多条件，那么你应该将这些条件拆分为更小粒度的方法。
• 经常重构你所编写的代码。不要害怕删除代码
• 在其它所有情况下，尽量保持代码的简洁。

想要做出KISS的方案，就必须对面对的问题有透彻的了解，有足够的经验和能力，并经过深思熟虑，这才能做出简洁的抽象。

一些世界上最大的算法的代码量总是很少的。并且通过阅读那些代码，我们可以很容易的理解其含义。算法的创造者，将问题简化简化再简化，最后再去实现它。很多最伟大的人，（他们）并不是编码高手，但是却创造了伟大的代码。

2. DRY 原则

DRY原则，Don’t Repeat Yourself

将重复的代码进行剔除，减少BUG，不一致性和冗余。

中文直译：“不要重复自己”。很多人可能会对这条原则会有误解，认为长得一样的两段代码违反了DRY原则。其实不然，重复的代码不一定违反DRY原则，而不重复的代码也可能违反DRY原则。

DRY原则三种典型的代码重复情况：实现逻辑重复、功能语义重复和代码执行重复

• 实现逻辑重复，但语义不重复，并不违反DRY原则。
• 实现逻辑不重复，但语义重复，也算是违反了DRY原则
• 如果代码重复执行，那我们也认为它违反了DRY原则

注：实现逻辑重复指得是代码重复，语义不重复指得是两个函数干的是完全不同的两件事情。

什么是代码的复用性？
这里有三个概念需要区分：代码复用性(code Reusability) 、代码复用(code Reuse)、DRY原则。

代码复用表示一种行为，我们在开发新功能的时候，尽量复用已经重复的代码。

代码复用性表示一段代码复用的特性和能力。（DRY原则上面已经介绍了。不要重复自己）

三． 设计原则

学习设计原则，学习设计模式的基础。在实际开发过程中，并不是一定要求所有代码都遵循设计原则，我们要考虑人力、时间、成本、质量，不是刻意追求完美，要在适当的场景遵循设计原则，体现的是一种平衡取舍，帮助我们设计出更加优雅的代码结构。

简单介绍一下七大设计原则：

开闭原则：是所有面向对象设计的核心，对扩展开放，对修改关闭
依赖倒置原则：针对接口编程，依赖于抽象而不依赖于具体
单一职责原则：一个接口只负责一件事情，只能有一个原因导致类变化
接口隔离原则：使用多个专门的接口，而不是使用一个总接口
迪米特法则（最少知道原则）：只和朋友交流（成员变量、方法输入输出参数），不和陌生人说话，控制好访问修饰符
里氏替换原则：子类可以扩展父类的功能，但不能改变父类原有的功能
合成复用原则：尽量使用对象组合(has-a)/聚合(contanis-a)，而不是继承关系达到软件复用的目的
 

1.   单一原则

单一原则（SRB）,意思就是一个类、函数只做一件事情，如下接口设计就不符合单一原则，因为此接口包含了对用户属性的修改的函数，也包含了用户的行为，因此此类就不遵守单一原则。

 那我们一般会怎么做呢？如下：将用户的属性相关操作跟用户的行为操作设计为单独的接口，各自负责各自的职责，这样设计会在使用层面造成不方便，因为我么是面向接口便编程，所以在使用的时候比较麻烦，所以还有更优解。

 但是这样设置不算完美，在实际的项目中我们的做法如下：就是单个类只负责做一类事情就叫单一原则。

 

 类的功能要做到高内聚（如sendMessage类应避免添加sendMail的功能及其属性）

单一职责（Simple Responsibility Principle SRP）是指不要存在多于一个导致类变更的原因。假设我们的类有两个职责，一旦需求发生变更，修改其中一个职责的代码，有可能会导致另外一个职责的代码功能发生故障。这样一来，这个类存在两个可能导致类变更的原因。如何解决这个问题，我们就要给这两个职责分别用两个类来实现，进行解耦。后期需求变更维护互不影响。这样的设计可以降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险。

用现在比较流行的网课进行举例吧，网课通常分为直播课和录播课，直播课不能进行快进，而录播课可以进行快进，功能职责不一样，先创建一个类：

public class Course {
 public void study(String courseName){
 if("直播课".equals(courseName)){
 System.out.println(courseName + "不能快进");
 }else{
 System.out.println(courseName + "可以反复回看");
 }
 }
}

从上面代码来看，Course 类承担了两种处理逻辑。假如，现在要对课程进行加密，那么直播课和录播课的加密逻辑都不一样，必须要修改代码。而修改代码逻辑势必会相互影响容易造成不可控的风险。我们对职责进行分离解耦，来看代码，分别创建两个类ReplayCourse 和 LiveCourse：

public class LiveCourse {
 public void study(String courseName){
 System.out.println(courseName + "可以反复回看");
 }
}
public class ReplayCourse {
 public void study(String courseName){
 System.out.println(courseName + "不能快进");
 }
}

2.   里氏替换原则

里式替换原则（LSP）是指如果对每一个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有对象o1都替换成o2时，程序P的行为没有发生变化，那么类型T2是T1的子类型。

引申含义就是，子类可以扩展父类的功能，但是不能修改父类原有的功能。

1.子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法。

2.子类中可以增加自己的方法。

3.当子类重载父类的方法时，方法的输入参数要比父类的输入参数更加宽松。

4.当子类的方法实现父类的方法时（重写、重载、实现抽象方法），方法的输出、返回值要比父类的输出、返回值更加严格或相等。

使用里氏原则有如下优点：

1.约束集成泛滥，开闭原则的一种体现。

2.加强程序的健壮性，同时变更时也可以做到更好的兼容性，提高程序的维护性、扩展性。降低需求变更时引入的风险。

现在来描述一个经典的业务场景，用正方形、矩形和四边形的关系说明里氏替换原则，我们都知道正方形是一个特殊的长方形，那么就可以创建一个长方形父类 Rectangle 类：

//父类 Rectangle 类：

 
public class Rectangle {
 private long height;
 private long width;
 @Override
 public long getWidth() {
 return width;
 }
 @Override
 public long getLength() {
 return length;
 }
 public void setLength(long length) {
 this.length = length;
 }
 public void setWidth(long width) {
 this.width = width;
 }
}


//创建正方形 Square 类继承长方形：

 
public class Square extends Rectangle {
 private long length;
 public long getLength() {
 return length;
 }
 public void setLength(long length) {
 this.length = length;
 }
 @Override
 public long getWidth() {
 return getLength();
 }
 @Override
 public long getHeight() {
 return getLength();
 }
 @Override
 public void setHeight(long height) {
 setLength(height);
 }
 @Override
 public void setWidth(long width) {
 setLength(width);
 }
}


//测试代码：

 
public static void main(String[] args) {
 Rectangle rectangle = new Rectangle();
 rectangle.setWidth(20);
 rectangle.setHeight(10);
 resize(rectangle);
}


//现在我们再来看下面的代码，把长方形 Rectangle 替换成它的子类正方形 Square，

//修改测试代码：

 
public static void main(String[] args) {
 Square square = new Square();
 square.setLength(10);
 resize(square);
}

这时候我们运行的时候就出现了死循环，违背了里氏替换原则，将父类替换为子类后，程序运行结果没有达到预期。因此，我们的代码设计是存在一定风险的。里氏替换原则只存在父类与子类之间，约束继承泛滥。我们再来创建一个基于长方形与正方形共同的抽象四边形 Quadrangle 接口：

//Quadrangle 接口：
 
public interface Quadrangle {
 long getWidth();
 long getHeight();
}

//修改长方形 Rectangle 类：

 
public class Rectangle implements Quadrangle {
 private long height;
 private long width;
 @Override
 public long getWidth() {
 return width;
 }
 public long getHeight() {
 return height;
 }
 public void setHeight(long height) {
 this.height = height;
 }
 public void setWidth(long width) {
 this.width = width;
 }
}


//修改正方形类 Square 类：

 
public class Square implements Quadrangle {
 private long length;
 public long getLength() {
 return length;
 }
 public void setLength(long length) {
 this.length = length;
 }
 @Override
 public long getWidth() {
 return length;
 }
 @Override
 public long getHeight() {
 return length;
 }
}

此时，如果我们把 resize()方法的参数换成四边形 Quadrangle 类，方法内部就会报错。因为正方形 Square 已经没有了 setWidth()和 setHeight()方法了。因此，为了约束继承泛滥，resize()的方法参数只能用 Rectangle 长方形。

3.   接口隔离原则

接口隔离原则（Interface Segregation Principle ISP）是指使用多个专门的接口，而不是使用单一的总接口，客户端不应该依赖它不需要的接口。这个原则指导我们在设计接口的时候要注意如下几点：

1.一个类对一个类的依赖应该建立在最小的接口上。

2.建立单一的接口，不要建立庞大臃肿的接口。

3.尽量细化接口，接口中的方法尽量少，但不是越少越好，要适度。

接口隔离原则是我们常说的高内聚低耦合的设计思想，从而使得类具有更好的可读性、可拓展性和可维护性。我们在设计接口的时候要多花时间去思考，要考虑业务模型，包括以后可能会发生变更的地方还要做一些预判。

那么我们来写一个动物行为的抽象：

public interface IAnimal {
 void eat();
 void fly();
 void swim();
}
public class Bird implements IAnimal {
 @Override
 public void eat() {}
 @Override
 public void fly() {}
 @Override
 public void swim() {}
}
public class Dog implements IAnimal {
 @Override
 public void eat() {}
 @Override
 public void fly() {}
 @Override
 public void swim() {}
}

可以看出，Bird 的 swim()方法可能只能空着，Dog 的 fly()方法显然不可能的。这时候，我们针对不同动物行为来设计不同的接口，分别设计 IEatAnimal，IFlyAnimal 和ISwimAnimal 接口，来看代码：

public interface IEatAnimal {
 void eat();
}
public interface IFlyAnimal {
 void fly();
}
public interface ISwimAnimal {
 void swim();
}
Dog 只实现 IEatAnimal 和 ISwimAnimal 接口：

 
public class Dog implements ISwimAnimal,IEatAnimal {
 @Override
 public void eat() {}
 @Override
 public void swim() {}
}

Dog 只实现 IEatAnimal 和 ISwimAnimal 接口：

public class Dog implements ISwimAnimal,IEatAnimal {
 @Override
 public void eat() {}
 @Override
 public void swim() {}
}

4.   组合复用原则

合成复原则（CARP）是指尽量使用对象组合、聚合，而不是集成达到软件复用的目的。可以使系统更加灵活，降低类和类之间的耦合度，一个类的变化对其他的类造成的影响较小。

继承我们叫白箱复用，相当于把所有的实现细节暴露给子类。组合、聚合也称为黑箱复用，对类以外的对象是无法获得实现细节的。

以数据库操作为例，先来创建 DBConnection 类：

public class DBConnection {
 public String getConnection(){
 return "MySQL 数据库连接";
 }
}
创建 ProductDao 类：

 
public class ProductDao{
 private DBConnection dbConnection;
 public void setDbConnection(DBConnection dbConnection) {
 this.dbConnection = dbConnection;
 }
 public void addProduct(){
 String conn = dbConnection.getConnection();
 System.out.println("使用"+conn+"增加产品");
 }
}

这就是一种非常典型的合成复用原则应用场景。但是，目前的设计来说，DBConnection还不是一种抽象，不便于系统扩展。目前的系统支持 MySQL 数据库连接，假设业务发生变化，数据库操作层要支持 Oracle 数据库。当然，我们可以在 DBConnection 中增加对Oracle 数据库支持的方法。但是违背了开闭原则。其实，我们可以不必修改 Dao 的代码，将 DBConnection 修改为 abstract，来看代码：

public abstract class DBConnection {
 public abstract String getConnection();
}
然后，将 MySQL 的逻辑抽离：

 
public class MySQLConnection extends DBConnection {
 @Override
 public String getConnection() {
 return "MySQL 数据库连接";
 }
}
再创建 Oracle 支持的逻辑：

 
public class OracleConnection extends DBConnection {
 @Override
 public String getConnection() {
 return "Oracle 数据库连接";
 }
}

具体选择交给应用层。

5.   依赖倒置原则

依赖倒置原则（Dependence Inversion Principle DIP）是指设计代码结构时，高层模块不应该依赖底层模块，两者都应该依赖其抽象。抽象不依赖细节，细节应该依赖抽象。通过依赖倒置，可以减少类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和稳定性，降低修改代码给系统带来的风险。

大家要切记：以抽象为基准比以细节为基准搭建起来的架构要稳定的多，因此大家在拿到需求之后，要面向接口编程，先顶层再细节来进行编程。

还是以保险为例，张三想要去买一个保单，这个保单中有两个险种，一个是重疾险，一个是意外险：

/**
 * 张三要买保险
 */
public class ZhangSan {
 public void byBidDisease(){
 System.out.println("张三买了一份重疾保险");
 }
 public void byAccidentRisk(){
 System.out.println("张三买了一份意外险");
 }
}
调用一下：

 
public static void main(String[] args) {
 ZhangSan zhangsan = new ZhangSan();
 zhangsan.byAccidentRisk();
 zhangsan.byBidDisease();
 }

不得不说，张三还是很有自我保护意识的，那么张三又想买一份定期寿险的话，就要修改原代码，在ZhangSan类中增加byAgeRisk方法，在main方法中也需要增加调用。如此一来发布代码风险是很高的，有时会代码意想不到的风险，那么要如何来优化代码。先创建一个byRisk接口：

public interface ByRisk {
 void buy();
}


//然后写重疾险：

 
public class BigDisease implements ByRisk{
 @Override
 public void buy() {
 System.out.println("张三买一份重疾");
 }
}


//在买一份意外险：

 
public class AccidentRisk implements ByRisk{
 @Override
 public void buy() {
 System.out.println("张三买了一份意外险");
 }
}


//再买一份定期寿险：

 
public class AgeRisk implements ByRisk{
 @Override
 public void buy() {
 System.out.println("张三买了一份定期寿险");
 }
}


//修改后的张三类：

 
/**
 * 张三要买保险
 */
public class ZhangSan {
 public void buy(ByRisk byRisk){
 byRisk.buy();
 }
 public static void main(String[] args) {
 ZhangSan zhangsan = new ZhangSan();
 zhangsan.buy(new BigDisease());
 zhangsan.buy(new AccidentRisk());
 zhangsan.buy(new AgeRisk());
 }
}
 

这时候我们再来看代码，无论张三想买多少个险种，都不需要修改底层的代码，只需要创建一个新类并通过传参的方式告诉张三要买什么险种即可。实际上这就是依赖注入，注入的方式还有构造器注入和setter方式，这里就不举例说明了。

6.   迪米特原则

迪米特法则（LOD）是指一个对象应该对其他对象保持最少的了解，又叫最少知道原则，尽量降低类与类之间的耦合。迪米特原则主要强调之和朋友交流，不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称之为成员朋友类，而出现在方法内的类不属于朋友类。

现在来设计一个权限系统，Boss 需要查看目前发布到线上的课程数量。这时候，Boss要找到 TeamLeader 去进行统计，TeamLeader 再把统计结果告诉 Boss。接下来我们还是来看代码：

//Course 类：

public class Course {
}

public class TeamLeader {
 public void checkNumberOfCourses(List<Course> courseList){
 System.out.println("目前已发布的课程数量是："+courseList.size());
 }
}

//Boss类：

public class Boss {
 public void commandCheckNumber(TeamLeader teamLeader){
 //模拟 Boss 一页一页往下翻页，TeamLeader 实时统计
 List<Course> courseList = new ArrayList<Course>();
 for (int i= 0; i < 20 ;i ++){
 courseList.add(new Course());
 }
 teamLeader.checkNumberOfCourses(courseList);
 }
}

//测试代码：

public static void main(String[] args) {
 Boss boss = new Boss();
 TeamLeader teamLeader = new TeamLeader();
 boss.commandCheckNumber(teamLeader);
}

到这里，其实功能已经都已经实现，代码看上去也没什么问题。根据迪米特原则，Boss只想要结果，不需要跟 Course 产生直接的交流。而 TeamLeader 统计需要引用 Course对象。Boss 和 Course 并不是朋友 。

那么就要做出如下修改：

public class TeamLeader {
 public void checkNumberOfCourses(){
 List<Course> courseList = new ArrayList<Course>();
 for(int i = 0 ;i < 20;i++){
 courseList.add(new Course());
 }
 System.out.println("目前已发布的课程数量是："+courseList.size());
 }
}
 
public class Boss {
 public void commandCheckNumber(TeamLeader teamLeader){
 teamLeader.checkNumberOfCourses();
 }
}

写到这里，其实功能已经都已经实现，代码看上去也没什么问题。根据迪米特原则，Boss 只想要结果，不需要跟 Course 产生直接的交流。而 TeamLeader 统计需要引用 Course 对象。Boss 和 Course 并不是朋友，从下面的类图就可以看出来:

7.   开闭原则

定义：
开闭原则(Open-Closed Principle, OCP) 是指一个软件实体如类、模块和函数应该对扩展开放， 对修改关闭。所谓的开闭，也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架，用实现扩展细节。可以提高软件系统的可复用性及可维护性。开闭原则，是面向对象设计中最基础的设计原则。它指导我们如何建立稳定灵活的系统，例如:我们版本更新，我尽可能不修改源代码，但是可以增加新功能。

例子：
生活中的例子：小学生放暑假，老师布置了10篇作文。对于小学生而言，写完这10篇作文这个要求是关闭的，但是具体哪天写，一天写几篇是开放的，由小学生自己决定。

 

package com.xhc.test.design.openclosed;

/**
 * @author xuehuichen
 * @version V1.0
 * @Package com.xhc.test.design.openclosed
 */
public interface Moto {

    String getId();

    String getName();

    Double getPrice();
}



package com.xhc.test.design.openclosed;

/**
 * @author xuehuichen
 * @version V1.0
 * @Package com.xhc.test.design.openclosed
 */
public class CFMoto implements Moto{
    private String id = "";
    private String name = "";
    private Double price = 0.0d;

    public CFMoto(String id, String name, Double price) {
        this.id = id;
        this.name = name;
        this.price = price;
    }

    @Override
    public String getId() {
        return this.id;
    }

    @Override
    public String getName() {
        return this.name;
    }

    @Override
    public Double getPrice() {
        return this.price;
    }
}



package com.xhc.test.design.openclosed;

/**
 * @author xuehuichen
 * @version V1.0
 * @Package com.xhc.test.design.openclosed
 */
public class CFDiscountMoto extends CFMoto{
    private Double discount = 1d;
    public CFDiscountMoto(String id, String name, Double price,Double discount) {
        super(id, name, price);
        this.discount = discount;
    }

    @Override
    public Double getPrice() {
        return super.getPrice();
    }

    public Double getDiscountPrice() {
        return super.getPrice() * discount;
    }
}



package com.xhc.test.design.openclosed;

/**
 * @author xuehuichen
 * @version V1.0
 * @Package com.xhc.test.design.openclosed
 */
public class Test {

    public static void main(String[] args) {
        CFMoto cfMoto = new CFMoto("001","春风nk250",19800d);
        System.out.println(cfMoto.getName()+"售价为："+cfMoto.getPrice());

        CFDiscountMoto cfDiscountMoto = new CFDiscountMoto("001","春风nk250",19800d,0.85);
        System.out.println(cfMoto.getName()+"原售价为："+cfDiscountMoto.getPrice()+" 现售价为："+cfDiscountMoto.getDiscountPrice());
    }
}

 参考文章：七大软件设计原则_依剑行走天下的博客-CSDN博客_属于软件设计原则的是

设计模式 - 七大设计原则（三）- 迪米特法则与里氏替换原则_chimen9438的博客-CSDN博客

七大设计原则(一)：开闭原则_清风一阵吹我心-CSDN博客_实现开闭原则

四． 什么是“架构”

架构的目的在于确定系统边界，确定系统里各模块之间的依赖关系与模块的宏观输入与输出以及明确非功能性需求。

1.     画架构图步骤：

架构图类型

确认架构图关键要素

梳理关键要素之间关联

输出关联关系清晰的架构图

2.     判断架构图好坏

布局，颜色，逻辑

3.     架构图分类

业务架构，应用架构，数据架构，技术架构

4.     UML图

分为静态结构图和动态行为图，同时类图也有六大关系，分为泛化关系，实现关系，聚合关系，组合关系，依赖关系以及关联关系。

 

 

 

 

 

 五、架构图分类

在从一个初级程序员到架构师的修炼过程中，画架构图是一门必修功课。

我最开始画图的时候，一直搞不清楚该画什么样的图来表达，网上也找不到系统的资料。

这里整理了下这些年的知识储备，给一些刚迈入架构师或想要进入架构师行业的同学，一点点参考。

架构图是一个统称，按视角维度，可分为：业务架构、技术架构、系统架构、应用架构，下面贴一些自己画的图给大家参考，个人能力有限，如果大牛有不同的看法，还请指正，大家互相交流学习。

架构分类：

一、应用架构（平台架构）

站在整个平台视角，描述整个平台架构。

二、技术架构

技术架构，是从架构师的视角 描述服务开发使用到的技术栈

三、系统架构

系统架构是从架构师的视角，描述整个系统的结构、分层、部署方式

四、业务架构（产品架构）

业务结构，是从业务、产品视角，描述整个平台、或某个产品的实现。这张图是挪用的，非本人所画，仅为描述问题。

推荐2个在线画图工具

1. Processon  在线版，收费的，模板库比较丰富，可以克隆模板，画图比较方便。

ProcessOn - 免费在线作图，思维导图，流程图，实时协作

2. drawio  在线和离线都有，免费的，我经常用，可以存储在云上或者本地，我一般存在git上，比较方便。

Flowchart Maker & Online Diagram Software

附图1：T31项目要求

 附图2：T31项目时序图

  附图3：T31项目类图

  附图4：T31项目工程图

  附图5：T31项目架构图

  附图6：近期任务：