从提出“邦联制架构”到如今，已通过去了不少年，从自嘲和被嘲笑，
到被人认同和自我认同，真的是经历了地下天上的旅程。
验证了将近7年，“邦联制架构”终于写了出来，但愿能有人看到。程序员
企业信息系统与互联网信息系统有着迥异的天生渊源，老是貌似却质的远离。
“架构”这个概念，在原生的互联网世界，总能够被无限制的解读，也能够无限制的变化，
可是，在管理学帕金森定律、彼得原理和墨菲定理之下，企业信息系统的架构愈来愈体现康威定理的结果，
这就诞生了一个很是有趣的双视角信息系统概念：项目视角 和 企业视角 的软件项目目标区别。
项目视角是尽量达成项目目的，项目以后的事情，就变成了身后事，死仍是活只有天知道；
企业视角是让项目尽量的活下去，项目内的技术目标，应该就是退居二线考虑的了，
软件项目的企业视角，就是“邦联制架构”的思惟原点。数据库
之因此叫“邦联制”是明确区别于“集中制”和“联邦制”的一种软件架构（软件模块体系主子关系），
以松散的甚至不明确的组件关联关系，达到信息系统生存能力最大化的一种信息系统架构。浏览器
作信息系统最多见的思惟是“集中制”，核心思想是复用一切，代码量最小化，
以强内聚手段达到下降错误的目的，我通常理解为信息系统建设的一种防守策略，
是比较典型的传统工程化的思惟模式，在软件工程领域的体现。安全
另外一种信息系统架构是“联邦制”，在统一的标准（宪法）之下，进行模块化建设，
既遵照明确的最高法规，又可以根据每一个模块（业务领域）的实际需求调整内部的集约度，
以低耦合的手段达到封闭错误影响范围目的，我通常理解为信息系统建设的进攻策略，
这是工程化向社会化（业务化）迈进的一大步。架构
二者的结合，通常称做“高内聚低耦合”，成为程序员和架构师的最高原则，
进而衍生出众多的以功能层次、角色职责或业务领域进行切分的架构流派。
可是，多年过去了，仍然没有解决，大多数信息系统建设项目的焦油坑，
没法达到预期目的或者称之为“失败”的问题。
聪慧之人，借助敏捷开发、NoSQL、Git等技术手段，在互联网领域攻城夺地，
可是，一旦进入2B市场，面对企业级成建制的需求，同样会发生拖期、沟通不足、需求改动，
疲于奔命，依旧是靠领导、靠关系、靠其余项目的逼迫、靠台面下手段，
反正不是依靠产品的成果经过最终验收。模块化
那么，“邦联制”真的能解决诸上问题么？也许真的能够！
由于，“邦联制架构”的着眼点是“软件”的生存能力，而不是工程师们的系统完善度。
从系统的生存能力为出发点，考虑信息系统的架构，就应该会出现“该怎么样就怎么样”的结果，
就是当年邓爷爷教全部人的“实事求是”。设计
系统必定要“单点登陆“么？系统必定要统一“后台维护”么？
系统必定要“数据库集中”么？系统必定要统一“平台”么？数据必定要“仓库”化么？......
这些理所应该的“必定”有多少是业务的须要，又有多少是工程技术的“惯性”呢？开发
甲方业务领导，必然会提出众多的“统一”和“完整”，其中，有多少是真正要落实到代码中呢？
是软件工程人员“意会”的领导意图，仍是真正“实事求是”的落地方案呢？
由于，“邦联制架构”的目标是软件的生存能力，因此，此处暂不进行其模型的枚举，
仅做简单的案例陈述：
案例1：单一系统建设中，进行多套帐号体系的建设，让不一样的模块拥有不一样用户名和密码。
初看此案例，简直反人类的设计，多套记忆体系，即增长了用户记忆负担，又凭空增长了维护量，
可是，若是是业务公司有必定量的第三方外包业务，或者流动强的人员岗位，
业务岗位就客观的存在一个另外的“岗位维度”，按照“事实就求”的原则是否是应该独立设计呢？
勉强的角色和帐号权限界定体系，甚至是传说中的权限界定到“单元格”的数据安全体系，
真的是贴合实际需求的方案么？
案例2：客户端系统，经过网页控件集成浏览器页面，让Web系统降级为桌面系统。
这真是反人类中的反人类，对IT文明的剧烈璀璨，我相信这样的评价是大多数人的第一反应，
可是，做为若是客户端系统是主力业务系统，一体化的展现网页界面，应该才是最高工做效率的体现；
而不是，由于Mobile比Web高级，Web比Client高级，从而一切由于高级而高级，为了先进而先进；
从另外的技术视角看，将Client做为Runtime，将Web和Mobile进行集成，
也许正是将来Browser定制技术的前进方向呢，或者理解为重度的Hybrid桌面方案，
而不是通常架构师眼里的Low活。产品
总之，“软件”和“系统”的存活，才应该是“架构师”和“项目经理”第一个该操心的事情，
这个前提下才是“先进性”、“稳定性”、“可靠性”、“鲁棒性”等等其余的搞大上概念。it
今日由此开头，但愿从此继续，勉励本身大放阙词！