Principles - Clean Architecture 读后感 - Part 1

《Clean Architecture》是一本什么样的书？

废话之前先写结论，如果你有一个类似于架构师、技术负责人这种头衔，或者你是一个很优秀的工程师，想进行一些架构方面的学习，那么这本书是一定要认真看，建议看英文版，单词不难，很好理解。

Clean Architecture

《Clean Architecture》是《Clean Code》的姊妹篇，或者说是迟到的姊妹篇，作者 Robert.C.Martin 与其称号 Uncle Bob 想必不用介绍了，在“软件工程”领域，Uncle Bob 与 Kent Beck，Martin Flower 这些大佬一样，都是干货满满一生都在贡献的人。几年前我曾经读过《Clean Code》，至今都难以忘记这本书对我开发生涯的帮助，在不断的成长中，发现自己忍受不了所谓的垃圾代码了，我们应该追求更好的，更干净的代码。那么，除了写代码，在架构设计上有没有所谓的清晰架构呢？回首就发现了这本出了没多久的《Clean Architecture》。

private static void preCondition() {
    String totalPrice = "";
    String[] products = null;
    double unitPrice = 0.0;
    int sumProducts = 0;
    String productName = "";
    Product product = null;
    for (String condition : PRODUCT_PRICE_CONDITION) {
        product = new Product();
        totalPrice = condition.split(" is ")[1].split(" ")[0].trim();
        products = condition.split(" is ")[0].split(" ");
        try {
            sumProducts = Cart.getTotalProducts(products);
        } catch (RomanException e) {
            System.err.println(e.getMessage());
        } catch (Exception e) {
            System.err.println(e.getMessage());
        }
...
        PRODUCT_UNIT_PRICE.put(productName, product);
    }
}

如果你还在写上面这种不太理想的代码，非常建议认真读读《Clean Code》，以及《Effective Java》，并且进行大量的练习。

严格意义上来说，架构或者“Architecture”是不存在所谓的标准定义的，我们有很多经验上的说法，比如软件架构这种词语常常描述软件的组成结构，经常有人会用建筑学的术语来类比，房屋的结构与软件架构是类似的，但是使用房屋的人会根据自己的要求是作为店铺还是住房，类似的软件的功能，往往不是架构决定的。架构在很多时候影响的是非功能性需求。想象一下你在大学毕业时编写的毕业设计程序，很垃圾，处处充满了不合理的设计，过度的耦合，不正确的抽象，模块之间没有清晰的边界，但是它工作了，它并不需要像一台家用汽车一样能开十万公里，它只需要让你毕业。

软件的特点与优势就是易于改变，易于改变也自然的成为了非功能性需求，我们希望更快的，更安全的响应需求变化，根据业务反馈调整系统，“最好今天就能上线”，这是业务人员想要的；同时我们希望软件易于理解，适合开发与测试，这是每个工程师想要的，方便测试能让你有信心进行每日部署，那么可部署性也是我们希望考虑的；我们还想能够简单方便的加入新功能，我们想降低耦合；我们想要更好的性能，我们也希望能够实现弹性以便适应横向扩展，所以也许会考虑无状态，这些都是在架构设计时，我们希望能够满足的非功能性需求。

所以《Clean Architecture》是 Uncle Bob 使用自己的经验来告诉我们在架构设计时，需要怎么思考，我们应该如何使用框架、数据库、语言特性、编程范式这些跟我们日常打交道的朋友，我们应该怎么去做架构设计。整本书中没有任何新的知识，没有新的编程语言，没有新的应用架构模式，毕竟这里老叔不是教我们写代码的。

那么有人肯定会说啦，羽辰你没有能跟大神比肩的知识与经验，也没写过著名的开源项目，你也谈架构有没有B数啊，我只能说，我没有！但是还是想总结与分享一下自己的学习心得，顺便联系下本人浅薄的经验与故事，那么，这篇系列博客大约是这样考虑的：

Principles：引子，重新回顾下我们常用的代码级准则。
Architecture：开始探讨 Uncle Bob 提出的清晰架构的知识点，业务与实现，high-level policy 与 low-level details。
Details：我们该如何使用框架、数据库、技术选型，在架构设计时我们如何让自己避免陷入 details。
Examples：通过具体实践故事来描述架构设计时的坑与心得，包括：keeps the options open, low-level details, main component 与 microservice。
Know your system：我们如果描述和理解系统，如何避免画那种色块式的架构图，如何做一个合格的 box drawer。

OO & 函数式

Uncle Bob 在书中分析了三种常见的编程范式（Programming Paradigm），结构式、面向对象与函数式，对于每种范式也给与了详细的解释，但是最出人意料的是最后的结论，比如对 OO 的描述中，Uncle Bob 并不认为封装、多态、继承（如果你用过 JS 这种“没有” class 的语言，在早期，人们也是通过几种办法实现了继承，可以参考我写的 JS 语言特性的文章）是 OO 的专利，但是 OO 最大的便利是多态，我们可以利用多态（Polymorphism）对系统中的每个对象进行绝对的控制，想想 Spring Boot 我们是怎么用的，完全的面向接口编程，业务逻辑的代码是不会在乎注入的对象到底是什么，这些则是 OO 带来的好处，就像 plugin 式的组合一样，根据配置或者 @Autowire，我们可以灵活的选择具体干活的是哪个 bean。

@Autowired
public ParkingListController(ParkingService parkingService,
                             @Qualifier("parkingViewModelConverter")
                             Function<Collection, CollectionViewModel> viewModelConverter,
                             DefaultParkingService defaultParkingService) {
    this.parkingService = parkingService;
    this.converter = viewModelConverter;
    this.defaultParkingService = defaultParkingService;
}

通过 @Qualifier 指定注入不同的 converter，这样的好处是在注入的时候你可以控制 bean，在 mock 的时候，你可以直接使用 lambda，因为 Controller 不需要知道 Converter 的实现。

函数式编程近年来火热，不可变所带来的安全性，使用流式的过程描述，尾递归、纯函数、高阶函数、一等公民这些东西的确让喜欢的人爱不释手，你完全可以使用函数式与杀手级框架做出稳定、强大、现代的应用，比如 Scala 与 Akka。我自己也非常的喜欢以至于不能忍受没有类似于 λ 功能的编程语。我也会在 Java 面试中问类似的问题，最狡猾的一个问题是，Optional.flatMap() 的返回值是什么类型？为什么一定要返回 Optional，这个方法签名的设计是遵循了什么？

for {
  account <- dao.getAccountByEmail(email).okOrElse(EmailInvalid)
  _ <- Option(account).filter(authenticated(password, _)).okOrElse(PasswordInvalid)
  email <- account.email.okOrElse(ErrorCode.UnknownError)
  passwordHash = retrieveHashedPassword(account)
  activated = dao.isActivated(account.uid)
  _ = dao.updateLastUsedTimestamp(account.uid)
  _ = logger.info(message("login.success", account.uid))
} yield createLoginReceipt(...)

这一段 Scala 代码使用 for 推导式来组织业务逻辑，就算是你不懂 scala，这些方法调用你也能搞清楚，这是先读取数据库，然后再做了某项事情。

回到自己的经验中来，大处 OO 小处函数式也许是目前最适合我的选择，OO 天然的描述性能帮助我们进行系统设计与建模，is-a 也许是世界上最方便的描述方法了，毕竟每个人开始学习 OO 时都是对现实世界进行抽象。函数式会让每个方法变的简单安全，可以通过强大的 for 推导式或者 stream 编排稳定的业务设计，并且由于不可变与无副作用，函数式的代码非常好测试，在 mock 时写一个 λ 就搞定了。即使是使用 Java 语言开发，我也将 Service 这种类定义成 @FunctionalInterface，因为实在是太好用了。

@FunctionalInterface
public interface OrderService {
    Page<Order> listAll(String clientId, Pageable pageable);
}

上面这个例子中 @FunctionalInterface 能让你使用 BiFunction 来模拟这个 OrderService，对于其他使用 OrderService 的类，BiFunction<String, Pageable, Page<Order>> 是一样的。

new ParkingListController(
    (a, b) -> page, 
    c -> c == parkingLot ? viewModel : null,
    clientId -> Optional.empty())

所以我们在测试中可以直接使用 λ，它会不断的提醒你，Controller 的行为是和内部的 service、converter 实现细节无关。

public static <T> void assertViolationType(Set<ConstraintViolation<T>> violations, String field, Class c) {
    assertTrue(violations.stream().filter(v -> v.getPropertyPath().iterator().next().getName().equals(field))
            .anyMatch(v -> v.getConstraintDescriptor().getAnnotation().annotationType().equals(c)));
}

public static <T> void assertNoViolation(Set<ConstraintViolation<T>> violations, String... fields) {
    List<String> fieldList = Arrays.asList(fields);
    assertTrue(violations.stream().noneMatch(v -> fieldList.contains(v.getPropertyPath()
            .iterator()
            .next().getName())));
}

stream 完全可以替代循环，帮助我们专心干业务上的事，我们就可以不用思考 index、中间件变量、结果导出等等这些细节。

设计准则 & 组件准则

这一部分 Uncle Bob 回顾了一下《Clean Code》中非常重要的部分——SOLID。这里笔者就不一一列举，这五个准则可以说是 OO 中最重要的设计规范了，我们在这里重申 SOLID 是为了让架构实践有更稳定的基础，毕竟我们一直希望软件易于改变，易于复用，这些准则如下：

Single Responsiblity Principle (SRP) 单一职责准则：每个软件模块，只能有一个原因导致变更，而不是说每个模块只负责一个事务，这是很容易误导的地方。该准则强调的是内聚，即把面向类似业务的代码放在一起，在项目中你不会把跟数据库操作相关的事务放在两个类中，我们经常会把 connect、disconnect、query 这种方法放在一个 DAO 中，比如叫做 DatabaseOperator，那么只有在我们与 DB 有新的需求时（比如加入 timeout 或者支持设置隔离级别）我们才会去改变它，而我们不会因为新加入的 SQL 语句来改变 Operator 内部的实现，因为没有必要，这就是内聚，也就是作者提到的该类只为一个 Actor 负责。

Open-Closed Principle (OCP) 开闭准则：相信很多人都听过，对于软件模块也好、类也好，都应该遵循面对扩展开发，对修改关闭。开闭准则是为了让系统在避免大量的修改而做好扩展，在 Java 世界中，尽量避免去 Override 已有的方法逻辑，采用不同的实现是更好的选择，比如 EmailSender 与 SMSSender 可能都继承自 Sender 这个抽象类（或者实现接口），而不是 SMSSender 去继承 EmailSender 去覆盖其中的 Sender 方法。开闭准则也可以很好的保护实现，比如使用 Sender 的类是不需要知道是如何发送消息的，这些细节被隐藏了。

Liskov Substitution Principle (LSP) 里式替换准则：子类应该能够替换其父类，否则就不能把其设置为子类。一言简之，如果你在使用 instanceOf 来判断某个类具体是其子类的时，那么基本上就违背了 LSP，大多数情况下你使用 instanceOf 判断类型，然后必然跟进针对某种类型的特殊操作，这是非常危险的耦合。

你可以这样判断是否自己违背了 LSP：

每当对象被继承时，询问它是否满足“可替换”的关系。
检查对象的类型，并根据该类型有条件地执行某些操作，这个很常见，只要有 instanceOf 就会有这样的问题，如下：

public void move(Vehicle vehicle){
    
    // violates LSP
    if(vehicle instanceof ManualVehicle){
        //shift gear
    }

...
}

实现接口时抛出 NotImplementedException，也违背了 LSP。遗憾的是这样的危险代码很常见，即使是很多有名的库中。

class AutomaticVehicle implements Vehicle {
    
    public void shiftGear(){
        throw new NotImplementedException();
    }
...
}

Interface Segregation Principle (ISP) 接口隔离准则：该准则鼓励我们避免依赖在不需要的接口上，鼓励我们使用小接口代替大而全的接口，特别是在 Java 语言中，一个类是可以实现多接口的，所以你可以根据需要去进行实现。

public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory,
        MessageSource, ApplicationEventPublisher, ResourcePatternResolver {

Spring 的 ApplicationContext 是一个特别有意思的例子，首先它是一个接口，但是它聚合了很多小接口比如 EnvironmentCapable, MessageSource，这些小接口是互相隔离的，但是 ApplicationContext 的实现类却必须实现这些小接口，ApplicationContext 是接口的聚合。

Dependency Inversion Principle (DIP) 依赖翻转准则：该准则告诉我们，灵活多变的系统应该依赖于抽象而不是实现。我认为 Uncle Bob 这一句话说的很好，像静态语言比如 Java，use、import、include 等这种语言应该 refer 到接口、抽象类这种表示抽象的东西，而不是具体的某个实现。面向接口编程，也就是面向抽象编程，你不需要知道 Sender 怎么发送邮件，也不需要知道 DAO 怎么去处理数据库的事情，业务就是负责业务，而让他们负责具体的细节（也就是 Uncle Bob 常说的 Details）。那么注入是怎么一回事呢？

假设你的文本编辑器需要某个拼写检查的功能，大约是这个样子：

public class TextEditor {

    private SpellChecker checker;

    public TextEditor() {
        this.checker = new SpellChecker();
    }
}

这时候，SpellChecker 与 TextEditor 已经存在依赖关系了，TextEditor 直接依赖了 SpellChecker。本来控制代码依赖是由外向内的，但是 TextEditor 却控制了 SpellChecker，这个依赖方向是反的，所以被称为 Inversion of Control，IoC。那么，如果你需要检查的是中文或者德语，你必须要修改 TextEditor 中的 SpellChecker 为 ChineseSpellChecker 或者 GermanSpellChecker，这就是我们不想看到的。所以，我们会有大约是这样的代码解决这个问题：

public class TextEditor {

    private IocSpellChecker checker;

    public TextEditor(IocSpellChecker checker) {
        this.checker = checker;
    }
}

这就是我们常说的注入了，通过注入 IocSpellChecker 的不同实现，实现不同的拼写检查，而不是由 TextEditor 这个类来控制需要哪种实现。

而组件准则中，作者提出的 The Reuse/Reluse Equivalence Principle、The Common Closure Principle 与 The Common Reuse Principle 与 SOLID 很类似，甚至通用闭包准确（CCP）可以认为是 SRP 的组件版，这里就不浪费口水了。如果你所开发的产品是按照组件的形式发布，那你需要认真的读一下这几章，并且认真思考你的接口是否定义正确，组件是需要进行很好的向后兼容设计。

Principles - Clean Architecture 读后感 - Part 1

《Clean Architecture》 是一本什么样的书？

OO & 函数式

设计准则 & 组件准则

《Clean Architecture》是一本什么样的书？