Architecture - Clean Architecture 读后感 - Part 2

架构与架构师

对于软件产品来说，往往是用两方面的价值体现，行为与结构，行为方面的价值表现为业务上的实现，也就是你可以使用软件来定制、完成业务，获取收益，而结构上的体现则反映在架构上，良好的架构设计能让系统易于理解、易于开发、易于部署、易于维护，能够让我们快速响应需求变化。结构上的价值对于软件更为重要，因为它体现出了软件的“软”。这也是软件架构与建筑架构所不同的地方，建筑架构更多是追求稳定，而软件架构则是面向演进和变化。

作为架构设计的终极目标是，降低在软件产品的生命周期中的花费，并且最大限度的提高工程师的生产力。架构设计的目的不是为了让系统工作正常，回想一下每个人都在公司中遇见过所谓的“老系统”，这些系统复杂笨重，难以运维、部署，但是往往这些系统都工作正常，最少在是满足最开始的设计的。所以，架构设计时要尽可能的考虑到系统的生命周期，在这个周期中，让我们的系统能够有能力接受新的 option，这与框架、语言、数据库、中间件等细节是没有关系的。

作为架构师或者设计架构的人，首先必须是一位足够优秀的程序员，他们必须持续的写代码才能明白自己的设计是否正确与高效，如果只是画格子（box drawer）他们就无法真正的体验到实践架构时的问题与痛苦，也无法回答其他工程师所面对的具体实现问题，比如：我们是使用 Pageable 分页还是自己写？我们应该采用哪种中间件？或者使用 NoSQL 时，应该如何保证复杂查询的效率？或者仅仅是搞定一个诡异的 bug。

独立性

关于解耦（Decpouling），在我的学习过程中，设计架构和写代码是有很强的共通性的，我们都是在考虑抽象，考虑更好的表达与组合，只是写代码时组合的是方法或者类，这里有很成熟的设计模式可供参考，而架构设计更多的是系统与组件之间的组合。设计模式或者 SOLID 这些准则都指导我们去做解耦，我们不希望拆东墙补西墙，也不希望按了葫芦起了瓢。比如下面这段代码，将输入的解析与业务的处理放在一起是非常不明智的，实际上这是两个不同的功能。

public String translate(String input) {
   
    String currentLine;
    try {
   
        BufferedReader br = new BufferedReader(new FileReader(input));
        while ((currentLine = br.readLine()) != null) {
   
            boolean foundTranslator = false;
            for (Translator translator : translators) {
   
                if (translator.isMatched(currentLine)) {
   
                    translator.translate(currentLine);
                    foundTranslator = true;
                    break;
                }
            }
            if (!foundTranslator) {
   
                outputCollector.addError();
            }
        }
    } catch (FileNotFoundException e) {
   
        System.out.println(e.getMessage());
    } catch (IOException e)