一、拿到需求怎么办
(一)、数据模型分析
1、需求分析总结-数据模型分析
(1)、拿到需求，分析需求，总结出系统的整体业务流程和核心业务，及系统技术要求和性能要求
(2)、根据上面的功能需求，技术要求和性能要求选择适合的技术架构
(3)、针对业务需求对原始数据进行数据模型分析2、数据角色主要如下
(1)、原始数据
首先根据原始基础数据进行模型分析，总结这些数据的特点(2)、原始数据对象
经过对原始基础数据进行解析处理后封装后的对象，也就是业务流程要处理的对象(3)、业务数据
业务流程处理过程中产生的数据。该数据一般需要持久化或者用于某种场景(4)、数据存储
一般我们要考虑最终生成的业务数据的格式，然后决定选择适合的数据存储(关系型数据库或非关系型数据库等)3、数据模型分析指导方针
(1)、解析原始数据到业务对象
如原始数据可能来自，xml格式，json格式，excel表格，文件、数据库(来自其它关系型或非关系型 数据库)，自定义格式数据等。针对上面的各种格式的原始数据，考虑一些怎么解析方便转为自己需要的业务对象(2)、操作业务对象
根据业务需求，思考业务对象应该怎样设计，才能方便业务流程操作(3)、是否具有统计分析功能需求：
可能需要对数据进行相应的分析统计，即具有分析统计功能需求，所以业务对象和存储应该怎么设计 和选择(4)、数据的可复原度是否高：
要考虑到数据的可复原度是否高，在有些场景需要恢复到原始数据，或者经过业务操作过后以同样的 原始数据格式返回，所以要考虑到从业务对象到原始数据的转换是否方便(5)、对数据进行操作的效率要求：
尽量将业务数据以一种直接的方式存储到存储层中，避免从存储层拿到数据后需要再次解析，才能使 用，影响系统的效率(6)、数据存储的选择可以参考下面的4的数据结构介绍
(二)、分析业务需求
针对业务需求分析，进行【场景技术】选型和结合各种【设计模式】进行架构设计。
优先考虑现有技术是否能解决特定场景 ，如果没有再考虑使用设计模式来自己实现业务场景。(三)、什么是结构化、半结构化、非结构化数据
记得在课上，老师说，结构化数据就是我们关系数据库里的表，剩下的都是半结构化和非结构化数据，好比XML文档就是半结构化数据，WORD文档就是非结构化数据，大数据就是半结构化和非结构化数据。心中一直有一个疑问？难道大数据不应该包含结构化数据吗？实在学习数据库这门课时，就对这几个概念有所混淆，所幸今天在书中发现了比较清晰的解释，记录下来，方便以后参考。1.结构化数据
（1）定义：业界指关系模型数据，即以关系数据库表形式管理的数据
（2）简析：虽然专业角度上看，结构化就是关系模型的说法并不准确，但针对目前业内现状，还是定义为关系模型最为妥善，因为它准确的代表了我们传统上最熟悉的企业业务数据。2.半结构化数据
（1）定义：非关系模型的、有基本固定结构模式的数据，例如日志文件、XML文档、JSON文档、Email等。3.非结构化数据
（1）定义：没有固定模式的数据，如WORD、PDF、PPT、EXL，各种格式的图片、视频等。
（2）简析：区分半结构化与非结构化的意义在于，对两者的处理方法是不同的，非结构化数据大多采用内容管理方法，而半结构化数据基本没有有效的管理方法。4.总结
（1）结构化、半结构化、非结构化其实是按照数据格式分类。
（2）严格讲，结构化与半结构化数据都是有基本固定结构模式的数据
（3）半结构与非结构化数据与目前流行的大数据之间只是有领域重叠的关系，本质讲两者并无必然联系。
（4）业界有将大数据认同为半结构/非结构化数据，是因为大数据技术最初是在半结构化数据领域发挥作用，其本质是将数据处理技术与数据格 式混淆，是不正确的。(四)、数据模型分析、业务分析、代码设计时结合设计模式分析
主要从三个维度即【三种类型的设计模式维度】分析1、考虑对象的创建：是设计为单例还是多例(是否考虑使用工厂模式来构建对象)
简单工厂、工厂方法、抽象工厂、建造者、单例(双重检查锁、静态内部类、枚举类型)2、考虑各类对象之间的结构关系：为了更好的组织对象
适配器模式、桥接模式、组合模式、外观模式、装饰模式、代理模式、装饰模式3、考虑对象之间的交互行为
责任链模式、状态模式、中介者模式(类似springmvc中中央调度器的统一调度各组件交互)、观察者模式、模板方法(钩子方法)模式、策略模式、备忘录模式、访问者模式、命令模式二、优秀的程序设计思想
1、抽象
【1】抽象的目的
为了更好的解耦各种对象之间的关系，抽象层度越高，越有利于构建高扩展的架构设计【2】抽象层次
抽象程度越高，包含的内容越多，含义越广泛，细节越少
抽象程度越低，包含的内容越少，含义越少，细节越多【3】怎么抽象(步骤)
(1)、寻找共性、
(2)、进行抽象和提升抽象层次，
(3)、构建抽象金字塔2、分治
(1)、归并思想：归并排序
(2)、二分思想：二分查找
(3)、分治设计：复杂算法的分解
(4)、分层设计：分离关注，降低系统的使用复杂度(类似设计模式的外观模式)，通过分层将复杂的业务 逻辑分为多层，高层屏蔽底层的复杂的操作，对上一层提供简单的统一接口，每一层都 只为它的上一层提供服务，实现单层职责单一，如网络的7层、5层设计
(5)、竖切横切：以分布式数据库为例，对一个大型系统进行分库和分表操作(也就是对数据进行分片)，
分库：
针对业务对象的相关性，对一个数据量到且整合了多个业务的数据库进行分库，将 业务相关性大的表，从大库中分离出来形成一个独立的库放到不同的服务器上，减 轻单台服务的数据存储压力
分表：针对一张数据量过大表可以采用水平拆分，将数据以一定的分片算法将数据分散 到不同的服务器的同名表中，这样表数据量小，对表的操作效率才会快
实现分库分表：mycat三、两种程序开发模式
1、数据驱动开发模式
【1】关注点
关注数据存储和数据间的关系【2】分析过程
需求分析===》数据建模(ER模型)===》建库建表===》编写POJO,Dao===>编写service层===》编写controller(对外控制层)【3】优缺点
优点：各层功能职责清晰，开发流程简单，一种过程化开发。
缺点：由于所有的业务逻辑代码都是写在service层，所以随着业务需求的增长和项目推进，service层 的代码量过大，后台难于开发和维护2、领域驱动开发模式
【1】关注点
关注的是业务实体的设计和业务语义上的显示表达，将数据驱动模式中的service层的业务逻辑分散到了分析得到的业务实体对象中。这种开发模式的精髓在于对象的分析和事物的抽象。【2】领域驱动之四色建模法
这种建模由四种模型构成，分别为业务关键时刻、角色、人事物、描述(1)、各组成部分介绍
《1》、业务关键时刻
某一时间段或时刻一次业务过程的总结，如一次下单、一次流程审核《2》、角色
对业务关键时刻涉及的人事物按照一定规则抽象分类得出对应角色《3》、人事物
业务关键时刻涉及的人事物《4》、描述
对人事物的描述，一般对应某类人事物的共有属性，对象属性的抽象即描述(2)、建模分析步骤总结
《1》干什么？业务需求分析，找出所有业务关键时刻
《2》找谁干(参与者)？找出任务关键时刻涉及的人事物
《3》怎么分工？对人事物进行角色划分，便于分工。
《4》参与者具备什么特点？人事物进行描述，属性特点3、两种开发模式的总结
平时在开发中，可以结合两种模式进行开发，以数据驱动为主，领域驱动为辅。
我们将数据驱动模型中的service的业务逻辑代码可以使用领域驱动进行设计，在service层的下面，dao层的上面增加一层，该层设计中将复杂的业务逻辑层，分别分散到封装了数据实体的业务算法层【即以组合方式将数据实体封装到业务算法层，然后根据数据实体和业务需求，开发业务功能，供上层service统一调用组装，其实领域模型一般适合在一些小型的系统开发或是一些业务场景架构设计或算法设计上】四、架构思考
1、架构师的工作内容
(1)、协调枢纽、承上启下
(2)、提供项目的解决方案
(3)、快速定位问题2、怎么锻炼架构思想
(1)、提升架构思维: 不要死抠技术，重点要考虑解决方案，因为技术就是为方案和特定的业务场景服务的
把自己的思维提升到架构层，不要仅限于代码层
(2)、在编码时，要关注自己的上下游(调用下层服务、为上层提供服务)。从整个项目视角思考项目的整个架构
(3)、对于自己的经历过的项目，进行如下总结：
【1】、业务流程：项目的业务流程(核心业务是什么)
【2】、业务模块：业务模块有哪些，怎么进行的业务划分
【3】、服务划分：怎么根据业务进行的服务划分
【4】、服务间调用关系：服务间调用关系是怎样的，采用什么技术实现
【5】、服务部署：
部署系统：是linux还是window。
服务日志：怎么保存维护，
部署方式：如采用原始war部署到tomcat中，打springboot项目包,使用内置的tomcat作为web服务器
服务启动方式：java -jar命令启动。tomcat启动、shell脚本启动、linux中的服务管理启动 (systemctl管理服务的启停转)
【6】、技术选型：微服务项目、单体项目的技术选型
【7】、上面步骤选择的优缺点是什么
【8】、输出架构设计文档、概要设计文档
最终将这两个文档交给相应人员(如产品，开放人员)设计项目的原型图和详细设计文档，最终由开发着 手开发。
(4)、以后自己开发新项目也要思考上面的几个点，锻炼自己的架构能力3、程序员两种实力
软实力：技术
硬实力：沟通表达能力、总结汇报能力、协调组织能力、文档能力4、程序员怎么学习一门新技术
(1)、对于技术的学习推荐：每一类技术实现可能存在多种方式，对于同一类技术所有的实现不用都去敲一遍代码， 只去掌握好一个实现就行，其它的了解其思维就行了，因为没那么多时间，也没必要。你只需要知道，该技术 主要解决什么样的业务场景，能够对号入座就行。如消息队列的实现(kafka、rabbimq、rocketmq、
activemq等)你只需熟练掌握一个如kafka的使用即可。
(2)、了解该技术在什么样的需求背景出现的、该技术的出现主要是为了解决什么问题，处理什么样的场景。
(3)、怎么解决的：处理思维是什么，具体步骤有哪些
(4)、重点就是解决什么样的业务场景，对后期你对应业务场景的技术选型有很大的帮组5、项目按访问流量划分
(1)、小型项目
小型项目一般都是搭建给某个组织内部使用的， 小型项目一般访问量不大，
业务数据量可小也可大：如果大可能要考虑到数据的处理效率。
如果业务复杂，也要结合相应的设计模式或场景技术进行设计(2)、大型项目
大型项目一般是放在互联网上，访问流量大。此时要考虑服务的高可用、高并发、高性能、高吞吐量、安全等特性：【1】高可用
保证请求都能得到及时响应：
如进行备份冗余处理(服务冗余【集群搭建】、数据冗余【数据节点集群】)、异步队列、服务降级处理
这样可能存在数据不一致问题：如各数据节点的同步可能有延时，导致可能响应的数据不是最新数据
高可用和强一致性是一个矛盾体：<1>、CAP理论
C(一致性)：各数据节点要保存数据一致性
A(可用性)：请求都有响应，即使数据不是最新
P(分区容忍性)：多个服务节点间无法通信也能对外提供服务
舍去C为AP：保证可用性但不保证强一致性
舍去A为CP：保证强一致性，但不保证可用性
舍去P就是单体结构，就不需要考虑CAP，因此P是必须的<2>、项目怎么选择CAP
实际项目中一般选择AP，保证高可用，使用弱一致性，最终一致性来解决数据的一致性问题<3>、一致性分类
强一致性：数据复制是同步的
弱一致性：数据复制是异步的
最终一致性：随着时间推移，经过一段时间后，数据变为一致<4>、base理论
base理论是对CAP中一致性和可用性进行权衡的结果。我们再保证服务可用的同时，无法保证数据节点间的数据的实时一致性(强一致性)，一般采用最终一致性来处理。
ba(基本可用)：采用限流(mq)、降级(兜底方法)
s：数据节点同步允许延迟，产生中间状态
e：不保证实时一致，但保证最终一致性【2】高并发(包含高吞吐量)
异步消息队列、服务集群部署、多线程线程池机制【3】高性能
缓存、搜索引擎、异步消息队列、回调，多线程线程池【4】网络数据传输安全
安全协议、数据编码加密(对称非对称加密)、数据完整性判断(数字签名：加签验签)6、搭建简单的springboot项目需要考虑的要素
(1)、日志记录(logback)
(2)、是否需要缓存(redis)
(3)、事务：哪些业务过程需要进行事务管理
(4)、集成swagger实现前后端分离接口测试
(5)、统一异常处理(全局异常处理)
(6)、统一响应结果封装定义
(7)、使用mybatisplus代码生成器生成sevice、mapper、实体
(8)、调整实体、编写VO、DTO并实现三者之间的转换，三种pojo要提取公共属性封装到基础类种：如BasePo
(9)、配置mybatisplus对一些审计字段的自动填充、逻辑删除、乐观锁，分页插件