0阶段：项目的确立

项目背景：K12教育，是公司的主要业务。由于公司内部需要对资源、产品进行管理，添加标签，公司需要一套CMS系统对这些资源和产品进行统一管理，作为公司公共基础项目，为业务应用提供数据，最终能实现快速生产业务应用的目标。

基于项目的背景最初的设计如下：

CMS项目设计1.0

其实在这个阶段开发实现很快，但是在项目刚开始的时候，作为刚招聘入职的主要开发者的我的缺乏对整个项目了解和掌控，同时对CMS的作用认识并不够深。而在此需求上，产品加上了较为复杂的权限控制，资源和产品的审核机制，直接导致系统的复杂度大大提高，从而导致开发难度加大，开发周期加长。所以在此阶段，我更多的只会遵循产品的意愿，并没有对产品进行反思，只能是项目来了就做项目。

在开发完成后，面临过一个极其尴尬的局面。系统完全是按照公司上层的意愿去设计，但是由于系统操作相当复杂，流程极其繁琐，根本没有人愿意用，包括作为开发者的自己。

作用阶段：与应用发生交互

按照公司的意愿，在CMS1.0开发出来后，就要对应用提供数据。整体设计图如下：

CMS项目设计1.1

即使CMS没有得到公司内部使用，但是按照开发计划，我们也要开发业务应用。在接触到应用后，才知道业务的复杂性，因为产品分为：试题、试卷、微课、电子书、教学课例、教学课件、教学设计。而每个产品有自己的独特的属性，所以在提供接口的时候是根据每一个应用的需求去提供接口，业务中应该要自己处理的逻辑，CMS系统中都提供了相关的接口。这样做是的确做到了对应用友好，因为我自身也是业务应用的开发成员，但同时也自己在挖了一个坑。

困惑阶段：过多的业务逻辑、耦合度高

上一个阶段中，CMS过多关注业务的逻辑，直接到的后果就是：业务应用的需求变更严重依赖于CMS，作为也CMS的需求也直接影响到业务应用。导致双方优化困难重重，耦合度高。在这阶段中，我对业务应用开发者强调，没有经过CMS参加评审的业务需求都是不合理的。也导致了业务应用的需求间接添加都CMS系统上。

作为主要开发者的自己刚开始的时候还觉得这样是一条正确的道路，因为CMS生产了所有的产品，作为所有产品的源头，就必须对产品的用途也掌控的彻彻底底。就好比如一个极权主义的家长，必须掌控自己孩子的所有活动。我不否认这种感觉也相当具有成就感。但是当业务应用变化太快，我付出太多的时候，自己在接口维护和不断开发上也显得极其困难（疲乏）和应对不过来。这总不能我一直控制着应用的对于产品的相关需求？

演变阶段：新的契机，即业务拆分

在上一个阶段折腾了半年后，我还是搞定了出现的问题，毕竟业务应用也不会总一直变下去。由于业务的发展，出现了一个新的需求：同一个应用部署在不同地区会看到不同的产品。这就相当于是产品的发布系统，对不同的地区发布不同的产品。

受困于上一个阶段的痛苦，我决定设计一个新的发布系统，跟生产系统进行拆分，项目设计如下：

CMS项目设计2.0

这样设计的最初的目的有以下几点：

1.使应用不受生产系统的干扰

2.发布系统是一个可以作为稳定可靠的数据源头

3.在发布系统统一数据格式后，可以拥有多个生产系统，为其提供数据

但是很多事情一旦开启了，就会发生连锁效应。既然发布系统可以要求统一数据提供者的格式，那么为什么不可以统一对外提供的数据格式，减少对业务应用的需求的关注。同时，发布系统中，也不会过于关注生产者提供了具体什么数据，它只是负责存储数据和对外提供数据。除了制定一些共同点外，再也不关注业务的特殊需求。而业务的特殊需求还是交由给生产者自身去关注和实现。

由于可以允许存在多个生产系统，那么产品系统也可以进一步进行拆分。设计如下：

CMS项目设计2.1

这样设计也进一步解放了生产系统的创造力，彼此之间不再有过多的关联，耦合度大大得降低了。而一些业务的需求也由各自生产系统自行消化。这样设计对于应用来说，区别就是：对于应用是冷漠的，而且必须根据CMS提供的统一数据格式，结合自身的业务需求，对CMS提供的数据进行进一步调整和加工才能达到使用的要求，业务应用的开发者的开发者的工作量会有一定的增加，但是这本身就是应用自身应该处理的逻辑。

或许有人会问，这样设计只不过多了一些数据汇总、统一的规矩制定和代理功能，何须多此一举？但是没有发布系统，各自的生产系统都会提供自己的自己的列表，制定自己不同的数据格式，那样必然到导致接口过多和繁杂。对于业务的开发者来说必然要从生产系统中去找数据，会大大增加其学习和理解成本。再者有一些统一的公共参数的标识必须的统一的。例如：产品名称，有人习惯用title，也有人习惯用name，这样对于业务应用的开发者来说将会是一个痛苦的噩梦。

循环阶段：新问题的出现和寻求新的解决方案

在设计统一后，产品又提出了一个新的概念，资源和产品其实在用户看来都是资源，需要做统一的搜索。举个例子：电子书里面可以引用N个视频，但是电子书是一个资源，但是这个N个视频本身又是资源。

所以说，问题总会在业务不断发展中迸发出来。唯有不断地对架构进行演变，来适应新的业务需求。

总结

做了这个项目2年了，从对架构一窍不通，到目前对这个系统的架构划分清晰。体会最为深刻的是，需要和一群热情的同事不断进行沟通、合作、协调、相互学习，也要听取各方面的建议。同时，我的上级也放手让我自由去发挥，大胆试错。从而一步一步地深入了解项目，对项目进行反思，以及对项目进行整体的掌控。

什么是架构？其实就是各个构件和连接件之间的协调，形成的一个大的系统而已。越是大的系统，构件的会按其作用进行细分，构件复用度也会越高，虽然会在流程上损失一定的效率，但是却能大大的提高整体上的效率。

对于项目而言，一开始的架构大多只会是符合当前的需求，但尽量是简单的、灵活的、易扩展的。因为随着项目的发展，架构也必然会发生改变。那是因为：变，才是永恒不变的！