以属性为核心驱动的全领域通用架构设计原理
（简称：属性架构原理）
联系方式：13547930387
Email：[email protected]
一、个人声明
我，参加工作也有5年多了，是一名普通的不能在普通的程序员，一直在使用公司自己的产品进行开发，因此技术比较菜，此设计完全是按照自己天真的想法而设计的，如果有不合理或很搞笑的地方，请轻拍，由衷的希望大家能提出宝贵的意见；
根据此设计原理我也做了一个简单的（demo）架构来支撑和验证此理论的可行性，由于技术功底不太好，有不合理之处请大家谅解，也希望您能把更优秀的设计方案分享给大家，真心谢谢！
二、设计初衷
本人为一名普通的软件工程师，在实际的工作开发中真切的体会到，现在的系统基本上都是针对特定的领域进行的开发，但不管是哪个领域的需求都是在不断的演进，特别是运维在线系统，需求变化非常之快。
当然，现在也有很多架构大师设计了非常强大的架构，其扩展性、通用性方面都很强；但均是针对特定领域的架构设计，因此前面所述优点也是针对新需求在开发的时候更加具有扩展性和通用性（代码级别的），随着系统被修改的越来越来多，维护人员也变了一批又一批，系统变得越来越混乱，维护成本极速增加，面对新的需求更是力不从心；久之，此系统的生命也就终夷，这也就是行业常说的所谓软件生命周期--当然，优秀的架构设计和项目管理可以很大程度上避免上诉问题，但只是少数。
当下，大多软件公司都会涉足各行业的软件开发，针对不同行业都会从新设计架构，开发一套新的系统（如医药系统、企业门户、新闻门户、广告系统、商城系统等等），那如果有一套可以应对各行业需求的通用架构，在这基础上进行二次开发，那岂不是节约了很多成本，缩短了开发周期呢，这就是此设计的初衷。当然理想很天真，具体还的看效果如何。
三、想法由来
在很久以前的某某时刻突然灵感爆发，萌生了两种很有特点的主题网站；起初计划使用三方系统构建网站，随之便开始在互联网中寻找合适的系统，苦苦寻找了一段时间，但一直没有寻找到适合这两类主题的网站系统；免费的、付费的，均没找到满意的，无奈只能自己动手做了；但问题来了，靠我一己之力要完成两个系统的开发，着实有点儿困难，就算完成了也不知道要到何年马月了；我又想偷懒走捷径，希望做一套系统能满足这两个主题网站；但问题又来了，两类主题网站功能和内容上差别很大，如果要做一套系统来同时满足两个差别很大主题网站，如果还是按照现有的方式开发，那系统肯定会非常臃肿，由于是在线系统，后续的新功能扩展也是个麻烦；那么要实现这一目的，就只能从另外的角度去分析和构建系统架构了，随后我就开始了寻找他们共性的征途。
在分析的过程中，我也结合了现在工作中的一些需求和开发经验，实际工作开发的系统也是在线运维系统，需求不断；在整理以往需求时发现，其实所有的需求内容都是围绕着主功能在修改（如：为主功能增加新字段，增加附加或边缘功能），隐约的感觉到了其中的共性和规律，那到底是啥呢，陷入了思考中。。。
就是在上述两种因素的促进下，我开始了去探索如何才能解决我的疑问和困惑。
首先抛出几个问题：
1、我从类哲学的角度去思考，我们加班加点、通宵达旦的做这么多系统网站的目的和用途是什么？
2、用户与系统网站的关系到底又是什么？
3、这些系统在表现上有没有共性？
“用户”的定义：泛指系统外界的操作者和使用者，以及系统中为映射前者而定义的逻辑用户（账户）。说明：对系统操作者而言，并非只有人，还有系统，调度进程等。
四、现各领域系统整理归类
那就用几种比较有代表性的网站系统分析
1、新闻门户类网站系统，这种网站类型应该是互联网最普遍的了，虽然在展示形式上多式多样，但本质还是一样—提供阅读内容和信息录入；
2、购物类网站系统，这次网站展示的内容变成了一个个产品信息，每个产品都会衍生出来了很多属性信息，操作限制上也更多；
3、后台管理类网站系统，此类系统均是对前台系统数据和属性的管理（增删改查），以及各种权限配置的增删改查；
4、资源类、论坛类、博客类、企业黄页类以及各行业的门户等，都具有一个共性就是提供内容；
5、无界面的进程系统。
从上述对各领域系统网站的分类分析不难发现，他们都存在着很多共性。
1、数据内容：网站均是提供数据内容供浏览器者浏览，不管是什么类型的网站系统，都是提供内容显示，管理系统更多是体现数据关系--但它还是以内容显示啊。
2、展现形式：这个其实HTML页面标签已经为我们分类好了，如文本框、富文本框、下拉框、多选框、单选框、列表，还有什么，没了吧？
3、操作：浏览、编辑、上传、下载、拖动。
4、浏览者浏览网站肯定是以某种身份角色去操作---未定义（未登陆）的普通用户，定义了（登陆）的特定用户角色访问网站系统。
五、系统结构分析
但随着互联网的发展，业务需求越来越复杂，为满足这些要求，系统也越做越复杂。模块多，分类复杂，各种关系和权限交错。
以下是简单的描述了系统的组成：
我认为：我们在应对这些复杂需求而设计更为复杂系统的时候，却把系统最原始的初衷和本质给忽略掉了，那就是系统就是为了提供数据内容给用户浏览查看，用户从系统中获取所需信息----不然还有什么目的？
因此用户最关心和最在意的也是系统中数据内容，其他与内容关联的分类，参数，属性之类的数据，用户并不关心，或者也只是通过他们来获取到自己更需要的内容。
因此这些与数据内容关联的衍生出来的内容只是为了更好的去获取数据，不管他们怎么变化，用户最终关心的还是内容，至于其他的并不关心。
六、新理论下的网站结构演变
我们把系统处理过程简化，如下图：
从上图我们就很清楚的看出用户更关心的是数据，中间的环节用户并不关心，因此我们先把多余的内容放在一边，一个系统就成了下图了，
但多余的部分不可能直接就砍掉啊，那我们就把它归为一类吧----属性，用户获取相应的内容就是通过这一些列的属性来作为桥接的；
但我们并不是简单的提供内容给用户浏览，其中是附有条件的，比如内容被分类了，内容被设定阅读和操作限制，只能特定用户才能浏览和操作等；
因此我们不能让属性进行简单关联，而是存在很多限制，以致于让特定的用户能够看到特定的内容，那么我们就需要去建立规则，让属性能够按照用户特点提供相应的内容。
这里回答上诉三个问题：提供内容供用户操作（阅读、录入、选择等）。
七、属性架构原理
通过上述分析，那我们就可以对系统进行全新的分类方法来分类：
1、将系统中所有的内容都划入一类（不管是看见的，逻辑使用的）----内容属性；
2、这样，他们就都属于同类了，那么我们就为这类分类定义一个类别名----属性；
3、但将系统所有内容划到一起，势必数据非常多，为了更好的管理，将他们放到一个容器中管理---属性池；
4、属性之间也是有各种关系的，那么我们就的记录他们的关系；
5、然后定义各种规则，从池子中取出内容属性供用户使用。
因此，最终的架构原理：
原理说明：将系统所有内容定义为属性（数据内容和相关属性），再配置他们的关系，将这些属性与用户定义权限配置，这样就为用户与数据内容建立起了操作关系。
此设计理念也是符合当下的设计思想，即功能独立化，数据集中化的设计思想。
至此我的“以属性为核心驱动的全领域通用架构设计原理”就阐述完毕了。
八、基于原理的推演设计（demo）
简单流程图：
8.1、以下整个属性池的定义
8.2、关于属性关系配置和权限配置
8.3、流程图
8.4、系统框架
8.5、框架流程图
8.7、属性池的属性管理方式
说明：
1、所有属性都以一树形菜单展示；
2、并通过属性的各类分类来进行检索；
3、属性池中的属性是属于游离状态，还没有被系统使用；
4、属性只有被定义的属性组组成了才能被当前系统使用；
5、属性与属性组之间可以互相查看关联关系
8.8、属性关系配置
说明：
1、任何属性都可以作为关心配置的根属性；
2、如果一个属性已经配置了他的下级关系属性，那么其他属性关联了次属性就不需要在继续往下关联--否则无止尽；
3、属性与属性之间可以有关系算法来控制相互数据的变化；
4、属性的关系和包含关系直接控制了页面数据的暂时和业务逻辑的处理；
5、属性可以定义底数---初始值；
6、这里展开的属性为属性组的属性--及已经被此系统使用的属性；
7、关系算法分为简单算法、复杂算法、组合算法、自定义算法；
8.9、权限配置
说明：
1、这里展示的属性也是被系统用的属性；
2、每个属性都可以配置权限和级别权限；但如果没有配置将使用父级权限配置；
3、配置算法分为简单算法，复杂算法，组合算法，自定义算法；
九、未来展望
架构原理核心模块：属性池管理、属性关系配置管理、属性权限配置管理
扩展的模块：属性缓存中心管理，交互信息管理，校验中心管理，基础功能管理、消息管理等。
如果此架构原理得到了大家的认可，而且也有了人致力于为此原理设计相应的架构产品，往后每个模块都有丰富的产品支持，那么以后的开发就更加的简单了，当然还需要有人为这些模块之间定义规范协议，大家都遵循这些协议开发，就可以将这些零散的来自不同公司的模块产品随意拼接一起就完成了一个完整的系统开发，太完美了。
如此图片为属性关系配置，以后就直接可以图形化定义和配置：
其他的模块也如此。
十、以下是根据demo的设计架设根据新需求的应变流程
10.1、在原有功能中增加属性和相关的业务逻辑
10.2、为系统增加独立的功能模块
此！