背景
在参与过很多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恰恰尝试了这种不可能，采取了组装式。
