1.拿到需求做什么（一）、数据模型分析一、需求分析总结-数据模型分析（一）、拿到需求、分析需求、总结整体业务流程以及系统的核心业务，以及系统技术需求和性能需求（2），根据以上功能需求、技术需求和性能需求，选择合适的技术架构（3），根据业务对原始数据进行数据模型分析需求2、数据的作用主要有以下几点(1)、原始数据首先在原始基础数据的基础上进行模型分析，总结出这些数据的特点(2)、原始数据对象是经过解析和打包后的对象处理原始基础数据，即业务流程要处理的对象(3)、业务数据业务流程处理过程中产生的数据。数据一般需要在某个场景下持久化或者使用（4）。一般对于数据存储，我们需要考虑最终生成的业务数据的格式，然后决定选择合适的数据存储（关系型数据库还是非关系型数据库等）3.数据模型分析指南（一）、将原始数据解析为业务对象，例如原始数据可能来自，xml格式，json格式，excel表格，文件，数据库（来自其他关系或非关系数据库），自定义格式数据等。针对以上各种格式的原始数据，考虑如何分析转换成你需要的业务对象（2），操作业务对象根据业务需求，思考应该如何设计业务对象，方便业务流程操作（3），是否有统计分析功能需求：可能需要对数据进行相应的分析统计，即有分析统计功能需求，那么业务对象和存储应该如何设计和选择？恢复度是否高，在某些场景下，需要恢复原始数据，或者业务运行后以相同的原始数据格式返回，所以需要考虑是否方便从业务对象转换为原始数据（5）、对数据进行操作效率要求：尽量将业务数据直接存储在存储层，避免需要从存储层解析数据才能使用，影响系统效率(6)、数据存储的选择可以参考下面4的数据结构介绍(2)、业务需求分析针对业务需求的分析，进行【场景技术】选择，结合各种【设计模式】用于建筑设计。优先考虑现有技术能否解决特定场景，如果不能，再考虑使用设计模式自己实现业务场景。(3)什么是结构化、半结构化、非结构化数据？记得上课的时候，老师说结构化数据就是我们关系型数据库中的表，其他都是半结构化和非结构化数据。比如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中的中央调度器的统一调度）各组件交互），观察者模式，模板方法（钩子方法）模式，策略模式，备忘录模式，访客模式，命令模式2.优秀的编程思想1.抽象[1]抽象的目的是为了更好的解耦关系各种对象之间，抽象层次越高，越有利于构建高度可扩展的架构设计[2]抽象层次越高，包含的内容越多，含义越广，细节越少，程度越低抽象的内容越少，意义越少，细节越多[3]如何抽象（步骤）（1），找到共性，（2），进行抽象，提高抽象层次、（3）、构建抽象金字塔2、分而治之（1）、归并思维：归并排序（2）、二分思维：二分查找（3）、分治设计：分解复杂算法（4）、分层设计：分离关注点，降低系统使用的复杂性（类似于设计模式的外观模式），将复杂的业务逻辑通过分层的方式分成多个层次，高层屏蔽底层的复杂操作，提供简单统一的接口给上层，每一层只为其上层提供服务，实现单层单层职责，如网络的7层和5层设计（5），纵切和横切：以分布式数据库为例，在大系统上进行数据库和表的操作（也就是对数据进行分片），分库：针对业务对象的关联，数据量大，集成的数据库多个业务分库，将业务关联度高的表从大库中分离出来，形成一个独立的库，放在不同的服务器上，减少单个业务的数据存储压力。分表：对于数据量较大的表可以采用水平拆分，通过一定的分片算法将数据分布到不同的表中。服务器上的同名表，这个表的数据量小，对表的操作效率会很快。实现分库分表：mycat3.两种程序开发模式1.数据驱动开发模式[1]关注数据存储和数据之间的关系[2]分析流程需求分析===》数据建模（ERmodel)===》建库建表===》写POJO,Dao===》写service层===》写controller（外控层）【3】优缺点优点：各层功能职责明确，开发流程简单，一种过程式开发缺点：由于所有业务逻辑代码都写在服务层，随着业务需求的增长和项目的推进，服务层的代码量过大，后台很难开发和维护。2.领域驱动开发模式[1]侧重于业务实体的设计和业务语义的展示和表达，将数据驱动模式下服务层的业务逻辑分散到被分析的业务实体对象中。这种开发模式的本质在于对对象的分析和对事物的抽象。【2】领域驱动四色建模法本次建模由四个模型组成，分别是业务关键时刻、角色、人员和事务、描述（一）、各组件介绍《1》、某业务关键时刻A一个时间段或时刻业务流程的总结，比如一次下单，一次流程回顾《2》，将关键业务时刻涉及的角色、人和事抽象出来，按照一定的规则归类，得到对应的角色《3》,业务关键时刻涉及的人和事物《4》,对人和事物的描述，一般对应某类人和事物的共同属性，对象属性的抽象就是描述（2），建模和分析步骤总结《1》它有什么作用？业务需求分析，找出业务的所有关键时刻《2》给谁做（参与者）？如何在任务的关键时刻找出涉及的人和事《3》？划分人事角色，便于分工。《4》参与者有什么特点？描述人和事物，属性和特征3.两种开发模式总结通常在开发中，可以将两种模式结合起来进行开发，以数据驱动为主，领域驱动为辅。我们可以使用领域驱动在数据驱动模型中设计服务的业务逻辑代码。在service层下面，dao层上面加一层。在该层的设计中，将复杂的业务逻辑层打散，封装了数据实体的业务算法层[即将数据实体以组合的方式封装到业务算法层，进而实现业务功能根据数据实体和业务需求开发，供上层服务调用和组装。其实领域模型一般适用于一些小规模的系统开发或者是一些业务场景的架构设计或者算法设计]4.架构思维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)以后自己开发新项目的时候，也要思考以上几点，锻炼自己的结构能力。能力4.程序员如何学习一门新技术（一）。技术学习建议：可能有多种方法可以实现每种类型的技术。同类型技术的所有实现，不用敲一遍代码，掌握好实现一个就够了，看懂别人的思路就够了，因为没有那么多时间，也没有必要。你只需要知道这个技术主要解决什么样的业务场景，你就可以入座了。比如消息队列（kafka、rabbimq、rocketmq、activemq等）的实现，只需要熟练使用kafka等一种即可。（2）了解该技术是在什么样的需求背景下出现的，该技术出现是为了解决什么问题，应对什么样的场景。（3）如何解决：处理思路是什么，具体步骤是什么？(4)重点是解决什么样的业务场景，这对你后期针对相应业务场景的技术选型有很大的帮助。5、按项目接入流量划分（一）、小型项目小型项目一般是为某个组织内部使用而建设的。小项目一般访问量小，业务数据量可大可小：大的话可能要考虑数据处理效率。如果业务复杂，还应该结合相应的设计模式或场景技术进行设计(2)、大型项目大型项目一般都放在互联网上，访问流量大。这时要考虑服务的高可用、高并发、高性能、高吞吐、安全等特性：[1]高可用保证请求能够及时得到响应：如备份冗余处理（服务冗余【集群构建】、数据冗余【数据节点集群】）、异步队列、服务降级处理，可能存在数据不一致的问题：如果每个数据节点的同步可能延迟，可能响应的数据可能不同步最新数据高可用和强一致性是矛盾的：<1>，CAP理论C（一致性）：每个数据节点都必须保持数据一致性A（可用性）：即使数据不是最新的也响应请求P（partitiontolerance）：多个服务节点之间无需通信即可对外提供服务。C是AP：保证可用性但不保证强一致性。A是CP：保证强一致性，但不保证可用性。P是单一结构，所以不需要考虑CAP。所以P是必须的<2>，如何选择项目CAP在实际项目中，一般选择AP来保证高可用，使用弱一致性和最终一致性来解决数据一致性问题<3>，一致性分类强一致性：数据复制是同步的弱一致性：数据复制是异步的最终一致性：随着时间的推移，经过一段时间后，数据变得一致<4>、基础理论基础理论是CAP中一致性和可用性之间权衡的结果。我们在保证服务可用的同时，不能保证数据节点间数据的实时一致性（强一致性），一般采用最终一致性进行处理。ba（基本可用）：使用限流（mq），降级（pocket方法）s：允许数据节点同步延迟，并产生中间状态e：不保证实时一致性，但保证最终一致性[2]高并发（含高吞吐Quantity）异步消息队列、服务集群部署、多线程线程池机制[3]高性能缓存、搜索引擎、异步消息队列、回调、多线程线程池[4]网络数据传输安全security协议、数据编码加密（symmetricAsymmetricencryption）、数据完整性判断（数字签名：signatureverification）6、搭建一个简单的springboot项目需要考虑的要素（一）、日志记录（logback）（二）、是否缓存（redis)是必需的（3））、事务：哪些业务流程需要事务管理（4）、集成swagger实现前后端分离接口测试（5）、统一异常处理（全局异常处理）（6）、统一响应结果包定义（7），使用mybatisplus代码生成器生成service，mapper，entity（8），调整PO，写入VO，DTO并实现三者之间的转换。三个pojo需要抽取公共属性封装成基本类型：如BasePo（9），配置mybatisplus用于自动填充一些审计字段，逻辑删除，乐观锁，分页插件（10），使用hibernatevalidator来验证请求参数的合法性
