前景：

? ? 公司系统(部分)业务稳定但技术架构陈旧故开启了重构之路，自己后续也会单独开一栏作为重构回溯，目的是做一些自认为有用的笔记（别杠噢杠就是你对），希望能对大家有所帮助少踩坑，空时间多陪陪家人女朋友啥的；有误地方请不吝赐教；架构采用DDD架构设计进行推进，为了规避那种单纯翻译导业务代码存在。为了写不被别吐槽shit一样的代码，就学习Bog大叔智慧《架构整洁知道》它适合作床头书，需要经常翻翻，读个一两遍不配说总结。

1：概述

图是借来的：原图https://upload-images.jianshu.io/upload_images/4098122-35d38a5b2fe841d7.jpeg?

这一内容从宏观纬度，让读者思考“设计”与“架构”定义和目标，开篇提到设计与架构没有任何区别。一丁点区别都没有！软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。

三种编程范式（结构化编程、面向对象编程和函数式编程）与软件架构的三大关注重点不谋而合：功能性、组件独立性以及数据管理。

面向对象编程到底是什么？对一个软件架构师来说，其含义应该是非常明确的：面向对象编程就是以多态为手段来对源代码中的依赖关系进行控制的能力，这种能力让软件架构师可以构建出某种插件式架构，让高层策略性组件与底层实现性组件相分离，底层组件可以被编译成插件，实现独立于高层组件的开发和部署。

软件架构师应该着力于将大部分处理逻辑都归于不可变组件中，可变状态组件的逻辑应该越少越好。

2：知识点：

TDD概念：测试驱动开发

编程范式：

结构化编程
面向对象编程
函数式编程

测试只能展示bug的存在，不能证明不存在bug（一个程序用测试证明其错误性，不能证明其正确性）
面向对象是对真是世界建模；封装、多态、继承；以多态为手段对源码中的依赖关系进行控制的能力
数据存储模式：不存在删除和更新即CRUD中的UD不存在，不会发生并发问题
蓝绿部署?专业术语：AB发布模式即一套系统内尘封部分服务功能，部署到A机器不再有增量业务；以后所有相关服务请求流转A机器，B机器虽然同样系统但不再提供此服务，用做增量业务
依赖反转：interface-》implement（接口-》实现）；利用源码中的依赖关系，限制控制流跨架构边界

设计模式

我的简单理解：开闭原则是总纲，它指导我们要对扩展开放，对修改关闭；单一职责原则指导我们实现类要职责单一；里氏替换原则指导我们不要破坏继承体系；
依赖倒置原则指导我们要面向接口编程；接口隔离原则指导我们在设计接口的时候要精简单一；迪米特法则指导我们要降低耦合。

SRP: 单一职责原则。讨论雷雨函数之间的关系；任何一个软件模块都应该只对某一类行为者负责。
OCP: 开闭原则。将组件间关系、依赖按层次结构进行组织；一个设计良好的软件系统应该在不需要修改的前提下就可以轻易被扩展。
LSP: 里氏替换原则。指导类与继承关系的方法、指导接口与实现方法原则
ISP: 接口隔离原则。将不同的操作隔离成接口，不相互影响即组件聚合；在一般情况下，任何层次的软件设计如果依赖于不需要的东西，都会是有害的。
DIP: 依赖反转原则：设计灵活系统多引用抽象类型而非具体实现
- 应在代码中多使用抽象接口，尽量避免使用那些多变的具体实现类
- 不要在具体实现类上创建衍生类
- 不要覆盖（override）包含具体实现的函数
- 应避免在代码中写入与任何具体实现相关的名字，或者是其他容易变动的事物的名字

六边形架构：

以几个同心圆画出来的整洁架构示意图，从里到外，各层分别是

业务实体（系统级业务逻辑）
用例（应用级业务逻辑）
控制器、展示器、网关（接口适配器）
Web、用户界面、数据库、设备、外部接口（框架与驱动程序）

不应该让外层圆发生的任何变更影响内层圆的代码
最内层：通用，高层策略
最外层：最具体实现细节
业务实体（AcceptEntity）：封装业务逻辑：带方法的对象、数据结构、函数的集合、枚举类，非复杂字典表简单的Y/N定义为类（preFlagE）引入AcceptE 类中
简单结构体：边界传输尽量简单对象或函数function以参数调用形式传递数据（DB->DO Object -/->架构内层）；entity即domian领域模型，以大而全参数数据存在最内层，提供中间层组织或组装业务数据
in： DTO -> simple obj或function args ->DO -> DBmapper
out：DO ->Entity ->DTO
谦卑对象：认识自己的局限性，只发挥桥梁和通信作用不干预信息的传输