wangbuji的博客

比如：是否引入敏捷开发，是否微服务，是否容器化，是否devops等等，规划和完善研发的技术基础设施，形成自己公司的一套行业。技术规划类似技术远景。当前问题包括：代码质量，code review，编写速度，编译速度，快速上线，并行开发，第三方库，自动化测试平台，线上bug率，架构演进，开发技术水平及培训，新技术引入，开发人员熟悉业务等。通俗来说：技术规划，就是技术团队集体梳理接下来一段时间，围绕行业和公司业务需求，有哪些工作可以做，哪些方面可以优化，哪些先进理念、技术，平台，框架可以引进，可以落地实施。

系统安全架构设计，主要包含：物理安全，网络安全，系统安全，数据安全，应用安全。完整性(Integrity)是指要防止系统的数据和资源在未经授权情况下被修改；机密性 (Confidentiality)是指要防止系统的数据和资源在未授权的情况下被披露。安全架构需求分析主要包括以下几个方面：明确系统安全的最终目标，例如保护用户隐私、防止未授权访问等。根据系统的功能和业务特点，划分出不同层次的安全需求，并给予相应的优先级。对系统可能面临的安全威胁进行详细的分析和识别，包括外部攻击、内部员工策反等。

可扩展架构是指系统设计和构建时考虑到未来需求增长和变化的能力，能够方便地扩展和适应新的业务要求而不影响系统的整体性能和稳定性。这种架构允许系统在需要时通过增加资源或组件而无需进行大规模的重构或升级。面向对象开闭原则可扩展架构的重要性适应业务增长随着业务规模的不断扩大，系统需求也会随之增加。可扩展架构能够支持系统的水平和垂直扩展，确保系统能够容纳更多的用户、数据和业务流程，适应业务的增长。降低维护成本可扩展架构使得系统的不同组件相互独立，降低了模块之间的耦合度。

由于要进行线程同步，所以在访问量比较大，或者可能访问的线程比较多时，采用饿汉实现在访问量较小时，采用懒汉实现饿汉模式：线程安全//假如有一个全局对象A 构造函数里引用上文中饿汉形式的指针，//若在A构造函数构造之前以上单例并未构造出来，那就会有问题。class singleton{protected: singleton() {}private: static singleton* p;public: static singleton* inita...

架构图的画法

1.生产者消费者定义 生产者消费者模式是通过一个容器来解决生产者和消费者的强耦合问题。生产者和消费者彼此之间不直接通讯，而通过阻塞队列来进行通讯，所以生产者生产完数据之后不用等待消费者处理，直接扔给阻塞队列，消费者不找生产者要数据，而是直接从阻塞队列里取，阻塞队列就相当于一个缓冲区，平衡了生产者和消费者的处理能力。 这个阻塞队列就是用来给生产者和消费者解耦的。纵观大多数设计模式，都会找一个第三者出来进行解耦，如工厂模式的第三者是工厂类，模板模式的第三者是模板类。在学习一些设计模...

限界上下文就是“边界”，这与面向对象设计中的职责分配其实是同一道理。限界上下文的识别并不是一蹴而就的，需要演化和迭代，结合着我对限界上下文的理解，我认为通过从业务边界到工作边界再到应用边界这三个层次抽丝剥茧，分别以不同的视角、不同的角色协作来运用对应的设计原则，会是一个可行的识别限界上下文的过程方法。当然，这个过程相对过重，如果仅以此作为输出限界上下文的方法，未免有些得不偿失。需要说明的是，这个过程除了能够帮助我们更加准确地识别限界上下文之外，还可以帮助我们分析需求、识别风险、确定架构方案。整体过程如下图所

DDD按规则细分业务领域，细分到一定程度，DDD会将问题范围限定在特定边界，在该边界内建立领域模型，进而用代码实现该领域模型，解决相应业务问题。领域就是该边界内要解决的业务问题域。其越大，则业务范围越广。 领域可再划分为多个子领域，即子域。每个子域对应一个更小的问题域或业务范围。 比如酒店行业，一开始的酒店核心系统是单体架构，后来业务发展，开始转型中台，引入微服务。微服务架构就需划分业务领域边界，建立领域模型，并实现微服务落地。可根据业务关联度及流程边界将酒店领...

一 mvc架构先看看MVC三层架构和鲁棒图3元素对应关系。应用逻辑：如数据有效性验证、授权检查、开始结束事务等。业务逻辑：领域模型服务层需要包含应用逻辑、用户会话的管理，但不能包含领域逻辑、业务逻辑和数据访问逻辑； 领域层（领域对象）应该包含业务逻辑，可以处理与业务相关的会话状态.但作为商业应用的核心，应该具有良好的可移植性，不能对特定框架（如Struts、Hibernate、EJB等）产生依赖二 领域模型领域模型分为4大类：失血模型、贫血模型、充血模型、胀血模型。想要理解...

用例图主要用来描述客户的需求，包含参与者，用例，边界，关系。 用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户）。用例是从系统外部可见的行为，从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。1 包含基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。has a.

一 需求分析1 背景a 电脑普及，5G，带宽提升b 优质教师资源分布不均c 随时随地学习，封闭模式d 做题，技巧，提分e 疫情催化剂2教育场景：a 直播课，用户广，互动少b 录播课，互动性差，课件可复制。c AI互动课，录制+AI处理，思维，数学，编程领域d 小班课，10人以内，沉浸感强e 1对1课f 双师课，线下加盟店常用模式，远程授课+线下辅导老师维持秩序，解答。10-30人二 逻辑架构三 技术选型1 总体设计思路：五个统一：统一传输网络，...

一 基本概念UML五个视图，逻辑视图，物理视图自顶向下，自底向上系统，子系统，模块划分业务用例，系统用例水平拆分，垂直拆分二 实例

转自http://blog.youkuaiyun.com/nameisbill/article/details/54573692分别介绍这几种关系：UML关系：继承（泛化）、实现、依赖、关联、聚合、组合的联系与区别一、表示符号上的区别二、具体区别与联系1. 继承/泛化（Generalization）　　【泛化关系】：是一种继承关系，表示一般与特殊

什么是软件架构前言：软体设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。但是，越来越

。3) 类的属性即类的数据职责，类的操作即类的行为职责 一、依赖关系(Dependence)依赖关系（Dependence）：假设A类的变化引起了B类的变化，则说名B类依赖于A类。•  依赖关系(Dependency) 是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖

一 面向对象对象七大原则单开里依分组迪助记：一只手单独掀开里边的衣服，里面衣服的荷包好几个，每个荷包都分门别类的放置东西，分组了，具备这种分类思想的人，是无敌的二 23种设计模式创建型5：工抽建单原助记：工人抽烟，正在建设武器单元结构型7：享适代桥外组装助记：想必是带到桥外边去组装，防止泄密行为型11：中访解命策，责备观模，迭状助记：