距上一篇设计文章已经过去很久了，不读书三日即面目可憎，以后还是要常做设计思考，常更新的好
很多时候，在构建一个复杂的后台系统的时候，我们都会面临一个问题，那就是我们该如何安排我们系统的功能框架？这个问题不是一个小问题，从『用户体验要素』的五个维度来看，功能架构是优先级很高的层级，其决定了后续我们会如何设计各个功能页面。所以，在设计页面之前，我们必须先弄明白一个后台系统中，功能框架该按照什么样的规则进行搭建
一般来讲，系统功能架构的构建方式可以分为两种，我将其成为岛屿模型与母巢模型
岛屿模型
提到岛屿，首先我们脑海中浮现的画面会是碧蓝的大海中，大大小小的岛屿星星点点的散落其中。这是我们真实世界中的岛屿，而『岛屿模型』则指的是在后台系统功能架构中采用了类似于群岛一样的构建方式
具体来讲，一个复杂系统必然是由多种功能，多个角色，多项业务所构成的。而我们针对某一业务专门构建一个完整的功能模块，然后各个功能模块之间通过数据流的方式进行交流，这种功能架构搭建的方式我称之为岛屿模型
举个例子，一个完整采购系统中是由『采购』『审核』『结算』『报销』等多项业务所构成的，这个时候我们为每个业务都独立设计一个功能，比如『采购管理』『采购审核』… ， 这些功能模块都是相互独立的，然后通过之间数据的传输来进行交流。
这样的方式十分像我们现实中的群岛，各个岛屿就是一个业务功能模型，各个岛屿之间是相互独立的，但是通过大海上的船只往来进行交流，那个船只就是我们的数据流
母巢模型
『母巢模型』指的是通过分析系统业务，抽象出几个通过性极高的元素，围绕着这个元素打造出一个十分庞大的模块。这样的形式十分像科幻小说中虫族的繁衍方式，所有的虫族都是围绕着母巢而生的
举个例子，对于车商SaaS系统来说，所有业务可以说都是围绕两个元素展开的，『车』和『客户』。那么这个系统甚至就可以只有两个功能，『车辆管理』和『客户管理』。所有关于车辆有关的业务功能都一股脑的放在『车辆管理』中，所有关于客户的业务功能都一股脑的放在『客户管理』中。这样，我们就造就了两个无比庞大的『母巢』
两者的优劣
定义好了这两者的概念后，我们来谈谈实用的问题，看看这两种模型之间的优劣势
该采用哪种模型
分析好了这两种模型的优劣之后，那么什么时候该使用何种模型才比较合适？
业务独立，用户众多时用岛屿模型
在我们系统业务众多，各个业务之间独立性很高，且面对的是不同的业务对象时。我们应该采用岛屿模型，这样才能最大程度的保证我们为每个业务的设计都能够最符合其的要求，达成最好的用户体验
业务对象较为集中，用户较为简单时用母巢模型
如果我们系统的业务针对的对象很集中，并且我们的业务没有那么复杂的时候。建议采用母巢模型，这样能够很大程度减低开发的成本，无需重复造功能
最后结语
通过分析了两种系统功能搭建模型，我们在构建系统的时候可以根据系统业务的性质来决定采用何种模型才能够带来更好的用户体验。
但采用不同的模型之后还有很多的问题需要我们去进一步思考的：
『岛屿模型』中因为功能分散的原因，我们就需要有一些全局的通知机制来帮助用户快速感知各处的变化，例如我们常见的『工作台』
『母巢模型』同样有问题，因为功能模块较少的问题，会导致有些权限很高的用户，他们看到的页面功能操作将是无比复杂的。这个时候就需要我们思考如何规划
无论如何，这两种模型是优缺点都很明确的两种方式，分散还是集中，这不是一个是非选项，这是一个平衡的问题。如何在系统中不断平衡分散和集中的关系，从而构建一个完善的功能架构，这是每个复杂后台系统都需要好好思考的问题
