新开一贴 自己这些年做了很多应用的架构 有大的有小的 这个帖子会详细描述这些年总结下来饭几种架构方式和模式 也会介绍一些架构设计思路 希望大家互相学习
目录
1. 背景与概述
2. 典型应用架构模式
3. 应用架构设计思路
4. 万剑归宗

1.1 背景
目前本人就职于蚂蚁金服-支付宝 核心链路的架构师
工作近7年 从事架构6年 从一开始的外包项目到互联网浪潮时的移动项目最后到亿级规模的支付宝项目 大大小小做了十多个项目的架构
所以准备以此贴来整理和总结一下我的思路和模式 方便自己提高也可以和大家多多交流 共同进步
此外 在工作过程中我发现很多开发同学对应用架构不甚了解 很多概念的东西模模糊糊 水平和方法论也参差不齐 所以也希望我这个文章能帮助到大家

萌新前排露脸

dd

dd

大佬又来啦

前排支持大佬！

2. 典型架构模式
2.1 三层架构
2.1.1 架构详解
三层架构是最经典和最基础的一个架构思路和模式,这个架构模式太过于经典以至于我都不知道从何说起.
简单介绍三层架构,即在软件设计过程中,会从不同的职责出发,把应用分为三层.分别是,展示层.业务处理层和数据访问层.在不同的业务环境下,三层的职责可能会有细微差别,比如干脆没有展示的业务,那么展示层会变成一种和外围数据交互的一层.这三层的业务职责分别是
展示层: 用以对外交互,负责对外交互的处理与业务定义.
业务层: 处理核心业务逻辑,核心领域能力,业务定义与业务模型.
数据层: 用于处理和存储内容相关的业务逻辑,包括数据模型定义,数据源设置,orm框架使用等.
整个三层架构的业务职责视图如下

希望大家多多交流和沟通

dd

我们以一个App后端应用为例,分别解释每一层的作用和职责
数据层:
数据层负责和db打交道.比如我们使用的mysql.那么会定义mysql驱动,定义数据源和连接.同时如果我们使用类似mybatis这样的orm框架,也会在这一层进行定义和使用.
数据层会使用数据模型,通常以**DO结尾,标识这是一个数据模型.和数据表对应.
在数据处理层可能会遇到非常多且复杂的数据操作.比如分库分表,缓存管理.查询组装等.这里的每一部分都可以深入讲解,例如分库分表,需要了解拆分原则,查询,分布式事务一致性等问题,有机会后续再展开.
总之一句话.数据层是负责和db(存储)打交道的.
业务层:
核心业务处理逻辑,也是架构设计中最复杂的部分.会进行核心领域能力定义,领域模型组装,业务定义,串联业务流程.
比如一个商品列表.那么在业务层需要转换查询条件,关联查询标签,类目,商品库存.然后统一组装成商品列表返回给外围.
随着业务的发展.业务层会越来越复杂.我们可能会遇到业务层的继续拆分.比如定义原子业务操作和业务流程组装.这部分会和后面的业务流程架构模式相对应.我会在后续进行展开描述
业务层使用的模型是领域模型.举例来说.一个商品有 上架/下架 这个状态.那么在db中存储可能是0和1.但是在业务层使用的时候可能是一个枚举.这是模型之间的不同
总结:业务层就是写一堆代码实现业务逻辑的地方
展示层:
用于用户展示的逻辑.大家可以不必拘泥于"展示"二字.在目前restfull架构模式下.可能所谓的一个视图就是一个json或者xml模型.所以我建议可以理解展示层为一个外围交互的部分.用于接受请求,转换结果的部分.
在典型互联网异动应用开发中,服务器端的展示层会处理很多展示的内容.比如金额.如果我们用Long类型存储金额(单位是分).那么在展示层可能会转换成一个String: "1,000.99" 这种格式.
此外,包括接口权限管理,session管理,异常包装等等都在这里.

大佬来啦

顶顶

我来顶贴，难得有个前辈，能够指点我们方法少走弯路，不能沉

另外询问一下，请问有那些平台可以听到大佬们的讨论，或者一些比较系统性知识的讨论