引言
本文首先介绍了架构的重要性，随后从一个实际项目的重构过程作为主线，逐步引出主流的架构设计思想以及其所解决的实际问题是什么。通过阅读本文，你将学习到：架构的重要性；重构的几种模式；设计原则；DDD中领域思想；项目的可测试性；项目的可演进性。
实践背景介绍
本文涉及的项目主要用于腾讯云团队K8s集群管理的项目，其核心业务包括创建、升级、删除集群和节点、集群监控、巡检等。
旧工程简介
Dashboard是该项目最早的版本，主要包含API请求处理和异步流程执行等核心功能，是团队最早的核心模块之一。但是随着功能不断增加，Dashboard早期不合理的架构设计所导致的可读性差、扩展性差，无法单测等问题逐渐暴露出来且愈发严重。为了让Dashboard的质量往更好的方向改进，团队决定对其进行重构。
新工程简介
考虑到直接重写的代价和风险过大，团队决定采用「修缮者」策略，即重创一个工程，承载Dashboard新需求的实现，并逐步将旧功能迁移到新工程中，最终达到重写Dashboard的效果，Skipper就是这个新工程。在迁移过程中，团队对Skipper的架构设计经过了几次调整，逐步解决了Dashboard中存在的问题，最终得到一个较为合理的架构，本文记录了重构过程中的思考，和架构演变的过程。
架构的重要性
架构的目标
追求好架构的目的到底是什么呢？或者说，我们期望一个好的架构产生什么价值呢？一个好的架构，其终极目标应当是，用最小的人力成本满足构建和维护该系统的需求。也就是说，好的架构目标应当是降低人力成本，这里包括的不仅仅是开发成本，还有构建运维成本。而增加软件可变性就是架构达到最终目标的核心途径，即架构主要是通过增加软件的可变性来降低人力成本，毕竟，捏橡皮泥比你在石头上雕刻要轻松得多。
行为和架构哪个重要？一个软件的行为固然是很重要的，因为一个不能按预定行为工作的软件是不产生价值的，所以很多程序员认为能实现软件行为是最重要的，根本不该关心架构，反正坏的架构也不是实现不了行为，出了bug修复即可。我认为，他们忽略的是随着软件行为的改动，坏的架构将导致他们自己的工作越来越难以进行，改动的代码越来越大，bug越来越多，项目最终可能不可维护。
一个软件的架构虽然不直接表现在行为上，但其最大的特点就是良好的可变性，即使目前行为不符合预期，也能通过低成本的改动将行为改变到预期。可运行不可变软件，最终会因为无法改变而导致行为无法迭代或者迭代慢而变成没有价值。可变不可运行的软件，可通过迭代，变成可运行可变软件，所以架构比行为重要。
恶魔小时候也可爱
一个不太好的架构，在项目初期有时难以察觉，因为此时项目模块少，功能少，依赖关系显而易见，一切显得毫无恶意，甚至有点简洁美。但是，恶魔小时候往往也很可爱。随着项目的增长，模块增加了，开发人员变多了，恶魔长大了。架构带来的问题逐渐暴露了出来，混乱的层次关系，毫无章法的依赖关系，模块权责不清等问题接踵而至。
对开发人员而言，项目理解成本不断增加，添加小功能都要先理清好几个模块的调用关系，难以测试导致上线后bug防不胜防，组件无法复用。项目逐渐长成大家闻风丧胆，避而不及的“大恶魔”。虽然我们也反对过度设计，但是识别，或者说猜测项目未来符合逻辑的可能变动，将架构设计考虑进项目早期是十分有必要的，架构设计和调整应该贯穿项目的整个成长过程。
识别过度设计
架构设计是为了让未来的修改更加容易，但是未来谁又能完全预测准确呢，架构设计或多或少有一定猜测成分在里面，但是更多的是吸取IT行业几十年发展过程中前辈们的经验以及对业务特点的了解所作出的符合一定逻辑的猜测。那什么算过度设计呢？从架构的目的是降低人力来看，就是该设计目前没有任何强有力的逻辑能推出能在未来降低修改某种行为的人力成本，或者降低某种行为修改成本的同时，大大增加了另外一种行为的修改成本。
架构的理解成本架构是有一定理解成本的，甚至架构设计之初会增加一定的系统理解成本，但是一个好的架构理解成本一定不会很高，因为架构的理解也是人力成本。在理解架构设计的意图之前，因为其增加系统的理解成本而否定它的必要性是不合逻辑的。好的架构，其关键意义在于降低项目发展过程中整体理解成本。也就是说，架构良好的项目随着业务复杂度增加，项目理解成本增长也是缓慢的。
架构不合理的项目随着业务复杂度的增加，整体理解成本可能是指数增长的。
架构调整需要勇气
一旦你宣布进行项目架构调整，就是宣告现有项目架构不合理，也意味着他人将设计出比当前优秀的架构，这是一件非常需要勇气的事。因为调整的过程中，你会犯错，你需要进行一些猜测，你会和他人产生观点冲突，你有时甚至需要有点固执和执着。因为架构投资的是未来，但大部分人只着眼于当下。
重构方式
拆迁者模式
根据当前业务的需求对软件架构重新设计，并组织单独的团队，重新开发一个全新的版本，一次性完全替代原有的遗留系统。为什么不适合我们？主要有如下几项因素：人力消耗巨大，需要一边加新需求一边重写旧需求；无法确保新的工程的设计比旧的好；重写过程中可能出现业务遗漏。
绞杀者模式
保持原来的系统不变，当需要开发新功能时，重新开发一个服务，实现新功能，通过不断构建新的服务，逐步使遗留系统失效，最终替换它。绞杀者模式相对比较适合我们的重构需求，但是存在以下问题：不希望存在多个服务共存的问题；希望共享旧工程的CICD，运维，监控等能力；重构颗粒度过大，我们希望细到函数级别的重构。
修缮者模式
将遗留系统的部分功能与其余部分隔离，以新的架构进行单独改造。修缮者模式特别适合我们的需求。
Dashboard的架构
整体架构Dashboard核心功能分为两大块，一个是作为Web API Server，接收HTTP请求，另外一个是异步流程处理，用于耗时较长的功能，比如创建集群、集群升级等。
Dashboard整体采用MVC架构+Controller模式，这里的Controller模式是指通过不断重试，最终将目标对象设置到某种目标状态的模式，比如通过不断重试，将创建中的集群的各部分属性或者依赖的资源，设置到正常集群的状态。Dashboard的核心模块如图。
MVC Controller：用于接收HTTP请求，并调用Service进行业务处理；MVC Service：核心业务逻辑全部落在这一层；MVC DAO：DB相关操作都在这一层；MVC Models: 包含各个对象的字段，比如集群、节点等；Controller模式下的各个Controller：每个Controller逻辑差异很大，但是都是调用Service进行对象状态的初始化或者设置；Components：调用外部服务的模块都在这里，比如调用计算资源服务创建虚拟机、调用网络资源服务设置网络等。
Dashboard虽然有水平分层，但是每一层内部没有组件的设计原则，也没有代码规范，每一层基本都是单一一个包，包内代码质量不高，重复代码较多。
具体实现Dashboard的工程目录如下所示：每一层一个包。这样看来，Dashboard的分层好像还挺清晰的。确实，相对于没有分层，Dashboard采用MVC架构进行分层本身是有一定合理性的。
但是在具体实施的时候，却出现了很多问题，其中较为严重的是每一层只有一个包。比如Controller包中，所有请求，无论哪个业务模块的，全部放一起，根本无法区分哪些是集群相关的，哪些是监控相关的，哪些是节点相关的，哪些是网络相关的。
如果说Controller包一个文件一个请求还可以理解，那Service层整个只有一个包，不分模块，而且全是全局函数可维护性就很差了，由于核心业务逻辑全在Service层，Service的代码量是所有层中最多的，随着功能的增长，未来Service将越来越臃肿。其它层，如DAO，甚至Component也是一个包。
依赖关系混乱
Dashboard没有关注各个模块之间的依赖关系，只要不产生循环依赖就可以随意依赖别的模块，所以模块之间依赖十分混乱。这直接导致模块难以复用，例如Component包中部分代码依赖DAO，依赖Config，而DAO和Config又强依赖了配置文件和DB。这导致如果要复用Component包开发一个很简单的工具，都需要给工具准备Dashboard配置文件，甚至需要能连上DB。
各层之间权责不明
Dashboard虽然进行了分层，但是各层的权责并没有严格实施，导致MVC controller层和dao层也包含了大量业务逻辑，甚至有大量与service层重复的业务逻辑。
每层内部没有设计
Dashboard只划分了水平分层，但是对每一层内部，以及各层之间的通信方式没有做出规定，各层内部可以随意暴露公共函数。各层之间也是直接进行函数调用。
Dashboard的架构导致了哪些问题？
上一节介绍了Dashboard架构的基本情况，这节更详细的介绍在Dashboard的架构下所衍生出的具体问题，这些问题便是Skipper v1着重需要解决的。
贫血模型导致DAO层臃肿MVC Models层中的对象只有数值，没有方法，所有对象的业务逻辑，无论轻重，都在其他层，这种模型称为贫血模型。相对的，如果对象不仅包含数值，还包含基本的方法，例如自身生命周期设置，版本设置等等，就称为充血模型。
Dashboard是贫血模型，这导致DAO层比预期的要厚的多，因为包含了大量业务逻辑，比如设置默认字段，判断字段是否是有效值等等，这些本应该是对象自身才知道的业务逻辑。厚重的DAO层会导致DAO层难以通过Interface进行抽象，想换一种存储简直是不可能的任务。
无法单测
上文提到，Dashboard中依赖关系十分混乱，而且一层只有一个包，这导致想进行单元测试是不可能的，因为对一个简单的函数单测，你可能需要直接连DB，哪怕你函数里根本不查DB。
Dashboard中各层之间是直接调用全局函数的，并没有通过Interface进行隔离，这就导致想进行单测就必须通过Monkey来进行全局函数打桩，不仅无法并发单测，还对体系结构有要求，因为Monkey只支持AMD64体系结构。
模块划分不清
Dashboard只进行了水平分层，但是同层没有分模块，这导致：（1）想复用模块功能但是不知道对应的函数是哪个；（2）添加新功能不知道应该把代码写在哪。
Controller模式能力不足
Dashboard使用Controller模式进行异步操作，但是Controller模式在持久化和异步流程控制上能力较为薄弱。（1）流程无法暂停，无法取消；（2）流程参数和进度没地方存储等。
Skipper架构v1
整体架构
基于Dashboard存在的问题，我们设计了Skipper项目架构的v1版本，这个版本依然使用MVC分层，但是针对Dashboard的问题，重点关注了外部依赖接口化、DB依赖接口化、充血模型、Task异步流程、模块划分等。Dashboard到Skipper v1的架构变动如下图。
外部依赖接口化
在Skipper中，对外部服务的调用（Component）都用Interface进行抽象，任何模块都不直接使用Component的具体实现，这解耦了业务逻辑和外部服务，Component提供fake版本用于单元测试。
充血模型在Skipper中，Models层只会被core obj层和store interface所引用，所有其它模块都直接使用包含充血模型的core obj层。
在core obj中，每个对象都是充血模型的，其不仅包含一个或多个对象数据，还包含一些业务方法，比如将对象设置为升级状态，比如将对象生命周期改为deleting等等，也就是说，原来处于dao中的业务逻辑被上升到core obj中，使得DAO层薄到只有最基本的CRUD操作，这对后面DB依赖接口化有巨大帮助。
DB依赖接口化
由于使用了充血模型，存储层只有最基本的CRUD，我们很方便得加入了store interface来解耦系统和具体存储，store层还提供基于gorm的具体实现，以及fake版本的实现用于单元测试。
异步流程
为了解决Controller模式存在的问题，Skipper开发一个Task异步流程执行框架，用于执行一次性的异步流程，但依旧保留Controller模式的存在，其中Task Controller是Task异步流程框架的引擎。（1）Controller模式用于需要一直运行的全局性旁路，比如节点状态监控，Task执行监控等；（2）Task模式用于复杂的一次性流程，比如升级一个节点，升级一个集群等等。
Service分包
Skipper中也有Service层，和Dashboard不同的是，Skipper的Service会根据业务模块进行分包，比如一个包专门处理集群升级，一个包专门处理监控组件，一个包专门处理巡检等。Skipper的Service层依旧使用了全局函数，没有进行封装，我们后续将提到，这是Skipper v1版本存在的一个问题。
可测试
由于外部服务以及DB都可以用fake的了，Service层的代码是可以进行单测的。
为什么相对Skipper v1可以降低人力
案例：节点升级
节点升级功能是指将一批k8s节点上的组件版本从低版本升级至高版本，这是一个比较耗时的流程，所以不能在同步请求中直接完成，需要异步执行，且需要展示升级进度。由于节点升级是高危操作，一批节点升级过程中，需要支持用户随时暂停，取消升级。
Dashboard中开发过程：如果该功能在Dashboard中实现，大概需要以下流程。考虑节点升级请求参数比较复杂，没法存在现有表中，需要新建一个表用于存储节点升级的参数和进度。编写对应的Models。编写专门用于上述表的DAO层代码。编写一个Controller异步流程，要为该Controller专门实现暂停，取消等控制机制。编写专门的旁路进行监控告警。Service中实现节点升级核心流程。
由于无法单测，觉得写得差不多了，需要等待测试环境空闲时，部署到测试环境进行调试。注意，测试环境是公共的，别人可能也需要用。
Skipper中开发过程：如果该功能在Skipper中实现，将基于Task异步流程实现，大概需要以下流程：由于Task框架已经提供了参数，进度的存储，以及Task相关的DAO代码，所以不需要创建任何新的DB表；由于Task已经实现了统一的暂停，取消等任务控制机制，不需要编写相关代码；创建一个Task Handler，实现节点升级；Task有统一的监控，无需重复编写；由于Skipper是可单测的，在部署到测试环境之前，我们通过单元测试快速调通了核心逻辑；部署到测试环境进行集成测试，这时候Bug已经很少了。
Skipper v1存在问题
虽然Skipper v1解决了Dashboard存在的很多问题，但是其自身依然有很多不足，在新需求开发和旧代码迁移过程中不断暴露出来。
core obj过度设计
Skipper为了采用充血模型，在core obj中进行了封装，例如cluster对象，隐藏了Dashboard中的多个models结构体，隐藏了某些字段实际是JSON字段的，对外暴露出带有方法的cluster对象，设计时候考虑了多种集群存在的可能性，所以整个对象对外不是一个实体，而是暴露了一个Interface。
而在实际使用时，发现为了对外暴露对象属性，Interface中充斥了大量的Get的Set方法，显得很笨重，而且由于不同类型集群的差异并不体现在cluster对象本身，而是cluster的业务逻辑中，所以暴露Interface并没有达到抽象集群的作用。
全局依赖skipper v1认为像store，component中的外部组件都是单例的，所以使用了全局依赖。
使用全局依赖使得整个工程用的是一个DB，这样的方式至少存在以下几个弊端：（1）各模块DB是耦合的，无法分开存储，虽然目前所有模块确实共用存储，但是随着模块的成长，模块DB独立也是有可能的；（2）Component里聚合所有外部服务这使得使用任何一个外部服务，就会依赖于所有外部服务，使用Component的地方都需要从全局获取对应的Component，重复代码较多。
模块不内聚
虽然Skipper v1中，各层基本都按功能进行分包了，但是模块并不内聚，一些包之间依赖关系很明显，应该属于一个模块的不同部分，并且由于只使用了水平分层，模块的内部各层代码分散到项目各层中并和其他模块对应层代码耦合在一起。针对某一模块，由于Service层依旧使用了全局函数，除非有文档说明，否则无法知道该模块对其它模块暴露了哪些API，其它模块甚至可以直接读写该模块的DB。
例如集群监控模块，当1.16版本的集群升级时，需要更新对应集群的监控配置，Skipper v1中的实现是在集群升级代码中显示调用更新监控配置的函数，这就使得集群监控开发人员必须理解集群升级的代码并知道在哪里调用更新监控配置的函数，这使得集群生命周期模块和监控模块是耦合的。
进一步探索
为了解决Skipper v1中的问题，我们决定重新审视一下设计原则相关的指导。我们比较警惕过度设计，也不喜欢在Golang中使用过多设计模式以及层层封装，但是我们相信，设计原则是所有语言通用的，因为设计原则只是一种思考的方向，让你对架构的坏味道更加警觉。
架构设计原则
架构设计原则是软件行业几十年发展总结出的一些具有指导意义的思想，虽然在实践时，很难完全遵循设计原则，但是识别其中违反原则的地方，并控制由于违反原则带来的风险是很有必要的。
SRP：单一职责原则SRP是最容易被误解的原则，因为大多数人看到名字，就以为该原则指的是一个模块只做一件事，但其实不是这样的。SRP较为经典的描述是：任何一个软件模块都应该有且仅有一个原因被修改。
这里我更喜欢Robert大叔在其著作《架构整洁之道》中描述的：任何一个软件模块都应该只对一类行为者负责。这里的行为者是指一个或多个有共同需求的人。从我们的实践背景下，集群生命周期模块和监控模块是不同的小团队在维护，而skipper v1中，监控模块想支持集群升级时更新配置，却需要改动集群生命周期模块代码，这其实就违反了SRP。
OCP：开闭原则
OCP是Bertrand Meyer于1988年提出的：设计良好的计算机软件应该易于扩展，同时抗拒修改。OCP是我们进行系统架构设计的主导原则，其主要目的是让系统易于扩展，同时限制其每次被修改所影响的范围。实现方式是通过将系统划分为一系列组件，并且将这些组件间的依赖关系按层次结构进行组织，使得高层组件不会因底层组件被修改而受到影响。
Skipper v1中Task模式是符合开闭原则的，因为如果要添加一个新的异步流程，只要实现一个新的Handler即可，并不需要修改Task机制高层代码。
LSP：里氏替换原则
1988年，Barbara Liskov在描述如何定义子类型时候写下这样一段话：这里需要一种可替换性：如果对每一个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。面向对象语言中有另外一种解释：所有引用基类的地方必须能透明地使用其子类的对象。
当然，Golang不是面向对象语言，没有父类，子类的概念，但是里氏原则对于Interface的使用有着重要的指导意义，即：假设存在接口A的实现Aa和Ab，使用接口A的程序在传入的具体实现由Aa改成Ab时，行为不发生变化。在Skipper v1中，store层是符合里氏替换原则的，因为使用DAO版本的实现和使用fake版本的实现，store接口使用者行为是不变的。
ISP：接口隔离原则
ISP的定义十分直观：客户端不应该依赖它不需要的接口。在Skipper v1中Store中定义的接口违反了ISP，因为该接口包含了所有模块的数据库操作接口，基于ISP原则，我们应该让每个模块自己拥有并维护自己单独的Store接口。
DIP：依赖反转原则DIP主要指导我们系统各层的依赖关系：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
从具体实现而言，如果想设计一个灵活的系统，在源码层次的依赖关系中，就应该多引用抽象类型，而非具体实现。
在具体实施时，《架构整洁之道》中给出了4点建议：（1）应该避免在代码中写入与任何具体实现相关的名字，或者是其他容易变动的事物名字；（2）应在代码中多使用抽象接口，尽量避免使用那些多变的具体实现类；（3）不要在具体实现类上创建衍生类，Golang语言天生就符合这一点；（4）不要覆盖包含具体实现的函数，即别重写，在Skipper v1的Task模式中违反了这一条，因为Task模式为了减少代码重复，所有Task Handler都需要内嵌Default Handler，并重写其觉得需要修改的函数。
组件设计原则
组件设计原则是CCP：共同闭包原则，应该将那些会同时修改，并且为相同目的而修改的类放在同一个组件中，而将不会同时修改，并且不会为了相同目的的修改的那些类放在不同组件中。其实CCP是SRP有很多相似的地方，我们可以统一描述它们的思想：将由于相同原因而需改，并且需要同时修改的东西放在一起。将由于不同原因而修修改的东西放在一起。
CRP：共同复用原则
不要强迫一个组件的用户依赖他们不需要的东西。这个原则实际上告诉我们应该将那些会被同时用到的代码放在同一个组件中。
ADP：无依赖环原则
组件依赖关系图中不应该出现环。Golang编译器实际上已经帮助我们避免了循环依赖。
SDP：稳定依赖原则
依赖关系必须要指向更稳定的方向。这条原则告诉我们，一个我们预期会经常变更的组件不该被一个难以修改的组件所依赖，否则这个多变的组件也会变得难以被修改。这里所谓的稳定组件，就是指那些被别的组件依赖多的组件，不稳定的组件是那些依赖很多其他组件，但被其他组件依赖少的组件。有时候我们的稳定组件还是需要依赖不稳定组件，怎么办呢？我们需要在他们中间加入一层稳定的抽象层。
SAP：稳定抽象原则
一个组件的抽象化程度应该与其稳定性保持一致。SDP中提到，稳定的组件是不易修改的，这会导致整个项目的架构难以被修改，我们需要通过高度抽象这些稳定的组件，来让其接受修改。
借鉴领域驱动开发
领域驱动开发是一种用于复杂软件的架构设计思想，学习门槛比较高且对团队成员整体架构水平要求较高，其实并不适合完全使用在Skipper的开发中，我们只借鉴其中一部分适合于我们项目的思想。
水平分层
在Skipper v1中，我们依旧采用了MVC分层。但是领域驱动开发，以及《架构整洁之道》都提醒我们，应当存在一个应用层（《架构整洁之道》中称为Use Cases层）用于处理依赖多个组件的业务逻辑，各层之间依赖于接口而非实现，且下层不能依赖上层。比如创建一个包含三个节点的集群，就同时需要操作集群模块和节点模块。
领域划分与边界
在领域驱动开发中不仅进行了水平分层，还进行了垂直切片，将应用层以下划分成了不同领域（Domain），每个领域责任明确且高度内聚。领域的划分应该满足单一职责原则，每个领域应当只对同一类行为者负责，每次系统的修改都应该分析属于哪个领域，如果某些领域总是同时被修改，他们应当被合并为一个领域。一旦领域划分后，不同领域之间需要制定严格的边界，领域暴露的接口，事件，领域之间的依赖关系都该被严格把控。
领域事件
领域可以定义事件并发布到事件总线，如果对某个领域事件感兴趣，就可以订阅事件。领域事件可以大大降低各领域间的耦合，且对系统扩展性有巨大好处。例如在Skipper v1中，如果划分出了集群监控领域和集群生命周期管理领域，当有一天监控领域决定去掉集群升级过程中对监控配置文件的修改，需要在集群升级代码里找调用监控配置文件升级的地方。
而如果采用了领域事件，则只需要让集群生命周期模块发布升级完成事件，并让监控模块订阅或者取消订阅事件进而做出配置文件修改逻辑即可。
Skipper架构v2
参考前两文的探索，我们对Skipper v1做了一定调整。
整体架构下图是v1到v2的转变，其核心是加入是领域模型，形成高内聚的业务领域组件。
我们将v1中的service层切成两层，把跨多领域的业务逻辑上拉至application层中，让剩下的业务逻辑包含明显的业务边界；我们再根据各个业务模块的依赖关系紧密程度进行重组，形成领域，每个领域只处理自己领域的业务，每个领域对外暴露一套Service接口用于描述该领域对外暴露的能力，领域可以利用Event Bus对外发布事件，用于通知外部领域内正在发生的事；原来全局公用的存储层，现在分散到各个领域自行维护，不同领域可以采用不同的存储；原来放置全局的Controller和Task Handler，现在由每个领域自行管理，系统依然提供Controller和Task的引擎（由Task领域负责）。
这使得领域业务逻辑更加内聚；注意各模块的依赖关系，我们尽量遵循稳定依赖原则和稳定抽象原则，不稳定模块尽量依赖于稳定模块，如果需要让稳定模块依赖于不稳定模块，我们引入Interface进行抽象。
新领域孵化
我们可以肯定随着业务的发展，会有越来越多的领域被加入到Skipper中（目前已经出现“虚拟集群”领域）。当一个新的领域被加入到Skipper中时，根据上边的架构，我们只需要借鉴其他领域的设计，新建一个领域，并在让领域负责人在此领域中迭代需求即可，这过程中，新领域可以依赖其它领域，监听其它领域的事件等等，对其它领域而言都是无感的。
领域成长与独立
随着领域内业务逻辑越来越复杂，或者因为业务调整，存在某个领域独立出项目的情况（目前“集群监控”领域已准备独立），由于我们的领域是高内聚的，领域独立的难度并不大，对整个项目而言，也只是将剥离的领域从领域层转移至Infrastructure层，作为外部服务而已。由于领域之间总是依赖于接口或者依赖于领域事件，当领域独立时，依赖这个领域的业务逻辑是不需要进行修改的。
微服务化
可能随着领域不断剥离，项目的领域不断的成为独立的服务，当服务增多时，就需要引入更加统一有效的运维、监控、部署方案，我们相信这才是项目微服务化最自然的方式，我们倾向于项目尽量是单体应用。
为什么相对v1可以降低人力
案例：增加集群创建失败通知机制
功能简介：集群创建目前成功率虽然符合SLA，但是依然不是100%的，我们希望当集群创建失败时能第一时间通知我们。通知本身是一个比较简单的需求，完全可以分配给新人来做。
Skipper v1中开发：如果在Skipper v1中开发，我们面对的最大问题是开发人员必须知道集群创建失败的具体位置，这只有集群创建流程的开发人员才知道，为了加入通知功能，新人不得不去请教集群创建流程的开发人员，并且需要修改集群创建流程，由于修改了集群创建流程，还需要走测试，虽然通知功能的代码不多，但是由于要修改集群创建流程，导致了人力成本的增加。
Skipper v2中开发：如果在Skipper v2中开发，只需要单独创建一个领域，专门用于系统各种需要触达我们的通知，然后订阅对应事件即可，比如该例子中，就是订阅集群创建失败事件。这种开发模式，不需要修改集群创建流程代码，一切改动都在关键事件通知领域进行，且基于这种开发方式，就不会让事件通知代码散落在各个领域中。
总结
本文是一次Golang项目重构的思考与记录，首先讨论了为什么架构是重要的，又介绍了几种可行的重构方式。基于实际的项目，我们介绍了旧工程Dashboard项目的架构和其中的问题，针对这些问题，我们尝试着去设计一个更优秀的架构Skipper v1。
但是，随着迁移的进行，我们发现Skipper v1中依旧存在一些如模块不内聚，充血模型过度设计等问题，为了更好地解决已知的架构问题，我们参考了《架构整洁之道》以及DDD的一些思想，再结合Skipper v1的实际情况，设计出了Skipper v2的架构。