序
没有创新就没有进步，在热火朝天的大数据时代，我们需要的是沉住气，以不变应万变，以简单迎接复杂，用共性创造多样性。让架构变成共享，让架构形成组装。
背景
在参与过很多app的研发的基础上，以及对很多互联产品的业务方向的摸索下，分析对比目前比较流行的app框架设计模式后，自研了自己的app项目，在此项目的研发过程中悟出总结了一种全新的架构模式，UDN（UI - Data - Network）架构设计模式又称之为：面向对象的架构模式-- OOA（Object Oriented Architecture）
理念
UDN架构除了遵循低耦合，高内聚的思想之外，还融入了全新的思想模式，面向独立业务，面向独立编程，高度封装，傻瓜式运用，业务隔离，技术隔离，看似瓜分三国，实际一统天下。全局顺，部分散，序中有乱，乱中有序。
鉴于以上UDN设计思想可以看出，整个UDN的架构是一套耦合度特别低的架构，他不仅仅单纯的从技术出发，更是从产品的业务方向整合的一套适合快速迭代，使用方便的上层app架构。
现有架构的缺陷
现有的技术架构大家都是模仿，改进，随着业务的发展，架构变的越来越复杂，越来越深不可测，增加了架构的难度，尤其是随着新技术的更新，架构的重构变的是家常便饭，增加了额外的研发成本，一定程度上降低了工作效率。
另外一个重大缺陷是现在是技术共享的时代，每家公司各自研发着自己的架构模式，让整个业界的架构得不到一个统一的标准，让架构显的独立又冗余，不是一个良性的技术共享模式，恰是起到一个干扰的作用，导致一家公司新架构的出现，其他公司盲目崇拜和模仿并不一定提高了工作效率反而很有可能降低了工作效率。
最后，架构技术至今没有一套规范的共享模式，随着互联大数据时代的到来，架构需要演变成人人可架构的形式而不是专注于某个架构师的责任。
详解
UDN概要：
首先，作为一个架构师必须明确以下两个问题。
问题1：何为架构？
‘架构’两个字眼。不仅在开发界，甚至在每个领域都随处可闻，随处可见。前端谈架构，客户端谈架构，服务端谈架构，甚至连产品设计也会谈架构。架构似乎不再是针对某一个大的框架而言，而是已经深入到每一个细小的模块，比如我们在开始编码前都会说：先把架构想好。
但是，何为架构？一千个人有一千种想法，也会有一千个结论，所以没有固定的答案和标准，才会让架构显的那么重要和神圣，同时也是那么的难。
哲学上有句话：世界万物都有他的自然规律，有多样性也必当存在共性。因此架构也是如此。
所以，抽出共性，一个好的架构必须满足以下条件：
1. 可维护性。
一个好的架构一定要具有可维护性，并且维护成本低。对于快速迭代的产品，公司是不会花费太多时间去做维护的事。
2. 可扩展性：
在互联网爆炸的时代，用户的需求千奇百怪，日益变更，良好的扩展性可以解决多态的需求。
3. 方便性：
一套完整架构代码，是给研发人员提供便捷入口的，而不是让开发人员来学习android源码的，使用一定要方便，工作效率才会提高。
4. 安全性：
一切没有安全的设计如同一个纸老虎，随时都有可能被毙命的危险。所以安全性是一款产品的命脉，尤其是金融产品。
问题2：技术如何选型？
了解到了何为架构，当开始入手的时候还必须想清楚一个问题：技术如何选型？
现在的软件技术革新快之又快，很可能一夜之间，你所谓最新的技术都直接被贴上out的标签。如此看来，大家是不是又慌了？
但是，我想说的是谁说好的架构一定要用最新的技术？达尔文在生物进化论上早就说过：适者生存。
这句话仔细琢磨的话，并不一定是诠释竞争环境的，他也诠释着另外一句话：鞋合不合适，脚穿了才知道。因此对于一个好的架构，个人认为并不是求新，而是求存。
如何存，怎样存。不是技术说了算，而是产品的说了算。因此业务的方向直接决定你的技术选型。
总结一下，技术如何选型，作为一个架构师，你不能只顾沉迷技术，你还一定要清楚以下几点：
不懂技术的架构师连码农的资格都谈不上，而只懂技术不懂业务的架构师就像是花瓶，易碎。现在所有的公司几乎都是以结果为导向，所有的产品最终都是以商业化为目的，无论是是直接的还是间接的，天下没有免费的午餐，记住一句话：挣不到钱的产品都不是好产品！
所以作为架构师，你在设计你的架构之前一定要明确产品的方向，能一眼看到技术，也一定要有一眼看到盈利模式。
解答了以上两个问题，让我们回到UDN的架构设计模式。UDN的架构思想就是很直白的融合了这样一种思想，前面也有提到：面向业务。他的分层更简单明了。融入的是技术，彰显的是业务。技术独立，业务鲜明，使用简单。
UDN的架构总概：
图解：
如图所示，UDN的整个架构思想特别简单清晰。以网络为基点，以数据为支撑，以UI为展现的三层组合结构。囊括了目前所有架构的必备因素，也是UDN核心的哲学思想：从多样性找出共性，从复杂到简单。
下面针对每一层的思想做详细阐述。
1. UI：
在这里我为何不称之为View？View太狭隘，UDN想阐述的是所有能展现给用户的东西统称为UI，这是站在用户的角度抽象出来架构之一的组件。
从图中可以看出UI包含列表和图片，而图片和列表的组合称之为：内容。也就是用户最关心的东西和上层app的终极体现。
所有的互联产品，甚至非互联产品只要能让用户触及和看到的东西就是内容，而组成app的宏观展现其实就两种元素：列表和图片。
因此UI层的设计，说白了就是列表和图片的设计。可见UI层瞬间变的再简单不过了。
2. Data：
数据是UI的支撑层，是UI层的心脏。这一层是站在研发和技术的角度抽象出来的架构之一的又一组件。
所有对数据的设计，以及和上层UI的交互，绑定等。这是研发需要很了解UI展现前提下去设计特定的数据模型。
这一层的设计可归结为接口Api的设计和数据的绑定设计。因此，Data层瞬间也变的很简单了。
3. Network：
网络是Data层的支持，所有的数据来源主要都是基于网络，数据的获取和传输，安全性都在这里实现。
4. 总结：
UDN架构思想层次化，每一层又简单化，各层之间负责各自该干的事情，互不影响，只需要给上层提供api接口即可。理解起来简单，设计起来有针对性，每一层业务的角度也都不一样，同时也彰显了业务的独立性，不仅降低了技术的耦合，也降低了业务的耦合。
UDN的业务模型：
图解：业务模型在UDN的架构层上着重凸显在UI层，UI一层可以说全是业务层。所谓需求都是很多决策和调研的刺激结果，因此在UI层设计的时候，列表的设计，图片的设计要结合真实的业务模型，以不变应万变。针对于上层app，UI层是最需要花心思设计的一层。
UDN数据模型：
图解：UDN的数据层，以上提过主要来源于网络，还有本地数据库。这一层是站在技术的角度，是数据核心发电站也是UI内容填充的仓库。
UDN的技术模型：
图解：每一层互不干扰，只需要提供Api供上层调用。
亮点：
业务和技术融合且相对应
耦合度极低
架构清晰
编码独立，每一层的技术使用和设计可以随心所欲
扩展性极高，每一层都可以组件化甚至插件化
代码可读性高，使用方便。
难点：
较强的业务知识和业务逻辑
全面的技术点，比如UI层不仅考虑到naitive的东西还要兼顾web的东西
超高的封装水平
发散的架构思维
娴熟的技术能力
实现
图解：
1. UI层其实就是布局，layout的多样性即是布局的多样性，在这一层要求极高的业务知识，要求很清楚产品的业务走向。让架构掌握全局，而不是代码堆积需求。
2. Data层完全的数据层，只是提供给UI一个接口。这一层可以暴露很多可以定制的接口，比如server端的接口等，最大可能的做到扩展性，不是针对于一款app，而是所有的都可以套用这个框架。
3. Network层也仅仅是提供接口，也要最大可能的做到扩展性和定制性，甚至可以直接插件化，以一种sdk的形式对内或者对外开发。
前景
UDN的架构设计目前只是一种思想，还未形成完整的架构框架。但是纵观目前所有的上层app框架，无外乎就是UI，data以及Network这三个支撑点，而截至目前各个公司都有自己一套架构模式，却从来没有人针对最直接的app三要素进行架构尝试。
UDN的架构思想是源于本人总结很多，对比很多以及项目自己实践总结出来的一套架构模式，没有所谓的高大上，就是利用哲学的思想从复杂到简单，从无序到有序，从多样到共性而得出的一种新型的架构尝试。
UDN架构可以说是一种很接地气的架构，他的可组件化是对此架构的最大挑战，也是最大亮点，因为从来没有一栋建筑可以把中间的房子单独领出来。所有的建筑师都认为架构不可动，都是有一个整体，牵一发而动全身，而UDN恰恰尝试了这种不可能，采取了组装式的玩法，模仿模型游戏的组件拼接法，让架构更接地气，让结构更有层次，让架构更业务化和简单化。
如果UDN一旦形成可套用的框架，可想而知整个移动互联的app迭代是有多么的快，可能到后来不是大家各自研发属于自己的架构而是整个互联的架构组件都可以公用。
也许将来有一天，我们app的开发仅仅是用A家的UI组件，用B家的Data组件，用C家的Network组件，而你家可能单纯的就是组装。
这不是不可能，想想大数据时代，云服务，一切皆有可能，有共享才有机遇，有创新才能进步，有利益才能达成共赢。而UDN带来的是快速迭代，高效工作，资源和技术共享，恰恰顺应了时代的需要。用户都越来越懒了，开发同样也想越来越懒。
技术改变社会，创新让一切成为可能，UDN的架构思想是随时代而进化的产物。一旦演变成功，全互联受益。所以前景还是很看好的。
备注
UDN的架构思想，专属个人所有。如果你认同求转发，不喜勿喷！
