单体应用架构
架构总感觉理我很远，有时候感觉很迷茫。今天起我把我认识到的三种架构写出来，一是希望沉淀一下自己所学的东西，二是希望有人能指出我的不足指出，向大家学习。
第一篇 单体应用架构我会总结出单体架构的优缺点，和一般我在经历过的项目中单体架构所用到的技术，以及我需掌握的知识。
第二篇 垂直应用架构
第三篇 微服务
单体应用概念：
在项目中只需要通过引用把所有的功能集中在同一系统中实现
应用项目类型：
单体应用常用在 SCM、 ERP、CRM 等办公系统中。
下面一张图介绍单体应用架构： （三层架构）
描述一下各个层之间用到的框架技术 这里以我工作中所见所闻总结出。
UI ：WebFrom、MVC、WPF、HTM...等
概念：UI常用来和用户交互，美观体验性都会在这里有直接体现。
BLL:常用来处理业务，一个框架中的最重要部分我认为是业务逻辑层，因为基本上所有的操作都是在业务逻辑层中实现，一个架构的设计也都在业务逻辑层中体现，比如，（缓存）Cache、记录日志、以及我们在项目中用到的各个组件都是在业务逻辑层中，业务逻辑层在数据交互上起到承上启下的作用，因为处于表示层和数据访问层的中间.
DAL：数据访问层，用到的技术有Ado.NET,FE、微软企业库、等. 数据层也称为持久层、也有人叫数据固化层，可以访问数据库（对数据库的增添、删除、修改、查找）、各种文件，文档，
DB ：数据库，SQL Server、MySql等，（以前有次面试的时候面试人员问我、你数据固化在哪里，我回答的数据库，很不赞成这样去问（容易懵逼）（~o~））
单体架构的优点：
（1）易于开发：开发人员使用当前开发工具在短时间内就可以开发出单体应用.（IDE友好）
（2）易于测试：因为不需要依赖其他接口，测试可以节约相当多时间了。
（3）易于部署：你只需要将目录部署在运行环境中即可
单体架构的缺点
（1）灵活度不够：如果对程序做出任何的修改，修改的不只是一个点了，而是自上而下的去修改，测试时必须等到整个程序部署完后才能看出效果。在开发过程可能需要等待其他的开发人员开发完成才能完成部署，降低团队的灵活。
（2）降低系统的性能：原本可以直接访问数据库但是现在多了一层。一个功能点都需要在各个层写上代码
（3）系统启动慢：一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动时间延长。
（4）系统扩展性比较差：增加新东西的时候不能针对单个点增加，全局性的增加.牵一发而动全身。
希望不足之处大家可以指出 谢谢！