Tomcat目录结构解析

bin

执行文件所在目录
sh文件liux上的,bat文件windows上的

lib

依赖的jar包和tomcat源码编译后的jar包

conf

catalina.policy 权限相关 Permission ,Tomcat是跑在jvm上的,所以有些默认的权限。
server.xml:

Server节点->Service ->Executor(线程池)、Connector连接器
Connector连接器 用线程池的话,connector里面的maxThreads是无效的。
Executor (线程池)maxThreads 不设置的话一般是默认200

web.xml

DefaultServlet默认的,加载静态文件 html,js,jpg等静态文件。
JspServlet专门处理jsp。

mime-mapping 文件类型,其实就是Tomcat处理的文件类型。

log

日志相关的目录

  • catalina.xxxx.log
  • localhost-xxx.log

DDD-第六课

第六课-领域模型和软件资产的持续演进与沉淀

image-20200816194959598

本讲大纲:

1.从资产视角看软件开发;

2.演进式设计是软件开发活动的本质;

3.遗留资产的共存与改进;

4.重构支持设计演进,沉淀领域资产。

开发活动的业务价值和资产价值

image-20200816200232748

为什么强者恒强?

image-20200816200751251

1.资产复用;

2.质量提升;

3.迅捷响应;

4.数据洞察。

资产分类:

1.技术资产;

2.通用领域资产;

3.业务领域资产。

image-20200816201431611

领域资产是最合适的资产粒度。

领域资产的汉堡包隐喻:

image-20200816201934936

关键实践一:划分通用子域,提炼领域资产

image-20200816202041341

关键实践二:用契约描述资产能力和约束

image-20200816202143170

权利和义务

关键实践三:保持领域资产的持续演进

image-20200816202520592

演进式设计是软件开发活动的本质

image-20200816202912946

演进式设计:勇气和谦卑

一、敢于在信息不全时做出决策

1.问题域的渐进认知;

2.能力的持续提成;

3.避免过度设计。

image-20200816203236165

二、相信未来一定会变化,为变化做好充分准备

1.业务应用层的自动化测试

2.领域层的自动化测试

a.提供者测试;

b.消费者测试。

image-20200816203416607

三、始终假定自己可能不正确,并使用各种机会检验

image-20200816203754985

image-20200816203824245

统一语言!!!

遗留资产的共存与改进

遗留资产

image-20200816204117544

1.遗留资产充斥技术债务;

2.接口不清晰,边界模糊,副作用未知;

3.代码理解困难,修改可能导致不可预知的副作用;

4.往往缺乏自动化测试。

对待遗留资产的三种态度:

image-20200816211446630

对待遗留资产的第四种态度:

image-20200816211624330

四种基本实践:

1.使用防腐层;

2.在遗留资产上包装并暴露清晰的API;

3.找到遗留资产的接缝,进行扩展;

4.细分遗留资产的边界,进行逐步替换。

使用防腐层:

image-20200816212105436

在遗留资产上包装并暴露API:

image-20200816212316328

找到遗留资产的接缝,进行扩展:

image-20200816212516137

细分遗留资产的边界,进行逐步替换:

image-20200816212615496

image-20200816212628865

1.从价值出发;

2.找到尽可能小的边界;

3.使用自动化测试保护;

4.按领域模型定义接口;

5.编写适配代码;

6.编写新代码,完成替换。

重构支持设计演进,沉淀领域资产

image-20200816213028953

image-20200816213043851

image-20200816213134132

关注点分离是重构的核心要点:

image-20200816213204137

image-20200816213251997

image-20200816214628881

DDD-第五课

第五课-微服务规划:以领域为中心规划服务

image-20200808211545634

架构反应了重要的决策:

架构定义了系统在其环境中的基本概念或特性,体现在其元素、关系以及其设计和演化的原则。

Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its dedign and evolution.

——ISO/IEC 42010:Systems and software engineering

——Architecture description

技术演进降低决策难度,聚焦于解决真正的问题

image-20200808213249079

本讲大纲:

1.子域和限界上下文,从问题域出发分而治之;

2.微服务带来了真正的边界;

3.上下文映射、API接口和设计契约。

image-20200808213856766

软件的复杂性和关注点分离

image-20200808214249268

分而治之在解决复杂问题的同时带来更大价值:

1.各个击破;

2.独立进化;

3.易于复用。

image-20200808214532679

以领域为核心——领域和子域

避免过大的领域模型。用一套模型来描述整个软件系统并不现实

1.简化认知——人并不能同时记住太多概念,刻意地忽略;

2.隔离变化——分而治之,每次处理一个特定方面,隐藏无关信息;

3.聚焦重点——区分那些对业务最重要的因素和次要的因素。

DDD中的相关模式

1.核心域:简化模型。定义一个核心域,并将其与大量支持模型和代码区分开来。

提炼核心域中最有价值和最专业的概念,把核心变小;

将顶尖人才分配到核心域中;

把精力花在核心域上,发现深层模型,确保获得足以实现系统愿景的灵活设计。

2.通用子域:识别那些非核心的领域。

分离通用子域,并把它们放在单独的模块中;

不要让通用子域包含核心域的知识;

考虑分离通用子域的开发人员,最好是使用既有的解决方案。

3.领域愿景陈述:明确核心领域的价值主张。

篇幅不要超过一页;

价值主张需要明确——只提现本领域模型和其他领域具有显著差异化的方面;

尽早完成,并在产生新的洞解时及时解决。

image-20200808215558794

如何拆分子域?

最重要的原则:领域体现的是业务能力

1.能不能用一句话说清目标?

2.是不是有一组内聚的核心概念?

3.有没有可能成为一项独立的业务?

启发式原则:

1.观察业务流程;

2.观察领域模型;

3.观察分析过程。

在业务流程中识别领域

image-20200808215858392

image-20200808220033360

image-20200808220053381

image-20200808220110863

image-20200808220127259

在领域模型中识别领域

image-20200808220222829

image-20200808220336158

演进纬度

image-20200808220654942

领域和子域拆分的要点总结:

1.分而治之是复杂性管理的基本方法,而且有助于隔离变化,提升复用;

2.领域的划分应该从业务视角出发,而不是实现视角;

3.在业务流程分析和领域模型中自然地分解,并保持持续演化的心智;

4.区分核心域和通用域,并在核心域上进行重点投资。

限界上下文(Bounded Context):最好的工作边界和问题域一致的边界。

限界上线问是什么:限界上下文是一个显式的边界。

image-20200808221338866

限界上下文和子域

观点:如果你在构建全新的系统,请让限界上下文的边界和子域定义保持一致。

image-20200808221547214

用领域模型和统一语言抵御破坏边界的冲动:

障碍1:环境——认知不足和习惯思维;

障碍2:外部——客户压力;

障碍3:自身——缺乏抽象习惯,不注意关注点分离;

不正确的实现破坏了领域边界:

image-20200808222034948

point:评论获得的积分;

isAdminMessage:是否管理员的回复;

memberService:与point是一样的问题。

微服务带来了真正的边界

微服务是一种架构风格

image-20200808222400345

微服务和 子域/限界上下文 紧密相关

image-20200808222445557

以服务的方式实现组件化

image-20200808222551562

image-20200808222718357

围绕业务能力进行组织:

image-20200808222841695

子域和服务规划:以领域作为核心关注点,兼顾非功能性需求,保持持续演化

image-20200808223122703

服务是一种组件化方式

image-20200808223534541

微服务和限界上下文彼此呼应:

1.领域需要一个边界(限界上下文);

2.微服务带来了真正的边界;

3.领域需要具有明显的业务价值,并保持持续生长;

4.微服务倡导围绕着业务价值构建服务和团队;

5.在领域层使用领域模型指导服务划分。并不需要为每个构造块定义一个服务,但是构造块提供了服务拆分的良好参考。

上下文映射、API接口和设计契约

上下文映射

image-20200808224325524

共享带来耦合,转化带来损失。

上下文映射的模式:

image-20200808224413604

image-20200808224503653

image-20200808224741892

观点:

如果提供方接口变化带来了问题,但是消费方未能发现,是消费方的责任。

image-20200808225401468

客户供应商:

1.依赖方(可以有多个)是被依赖的客户;

2.依赖方和被依赖方共同开发自动化验收测试,并且加入到被依赖的测试套件中;

3.非常适用于被依赖方的领域模型需要探索的情况。

防腐层ACL

被依赖方对依赖方没有承诺;

被依赖方的领域模型质量不好,或者不符合依赖方的需求,或者依赖方不想和被依赖方捆绑在一起

image-20200808225720110

事件机制和上下文映射

事件是解耦业务领域的非常关键的方法

image-20200808225825200

image-20200808225907889

image-20200808230111909

DDD-第四课

第四课-高效高质量编码:测试先行和意图导向的编程

image-20200808194825189

本讲大纲:

1.由外而内——发现和形成设计职责;

2.测试先行——表达和实现设计契约;

3.持续演进——契约是设计质量的保证。

从哪里写下第一行代码?

image-20200808195110856

自底向上的编程是很多浪费和麻烦的开始。

一个小游戏背后的故事:

image-20200808195400656

image-20200808195432178

image-20200808195601010

image-20200808195642014

设计是一种信息不完全情况下的决策。

由外而内的编程:

1.一般来说,外层的功能比底层的功能具有更高的确定性;

2.延迟决策到最后时刻,关键信息经常会自然显现;

3.由外而内的编程允许暂时忽略不重要的细节;

4.由外而内的编程——》“意图导向编程”。

意图导向编程(Programming By Intention)

意图导向编程就是“想什么就写什么”,用代码来表述你期望的行为。

想象:编码过程中,假设已经有一个理想的方法支持你的工作,你会怎么编写程序?那就这样编写它。

image-20200808200328949

CollisionDetector的具体实现

image-20200808201222838

底层设计一半来说涉及更多细节;由外而内的方式,让底层可以随时被替换。

由外而内、意图导向编程的收益:

1.职责分配是在编码过程中即时完成的,设计和编码真正成为一件事情;

2.代码的可理解性可以得到保证(声明式编程),消除了大多数注释的必要性;

3.以终为始,逐渐导出设计契约;

4.延迟复杂的细节性决策,聚焦于当前阶段的关键行为;

5.利用了IDE的“自动纠错”能力,提升了编码速度。

由外而内编程的2个要素:

1.保持同一个层次的抽象;

2.合理分配职责。

image-20200808201859982

对象的职责在编码过程中自然产生:

image-20200808202050709

所以第一行代码应该从上往下,从功能开始,是最合理的方式,即先写应用层。

创建属性计划的Service:

image-20200808202336406

应用场景驱动,促进领域对象和领域服务的职责持续生长

image-20200808202541403

由外而内,意图导向的编程要点小结:

1.从应用场景出发开始编码;

2.意图导向,描述期望的程序行为,同时完成职责分配;

3.逐层深入,重复上述步骤;

4.涉及领域层对象时,要结合领域对象的职责考虑,并合理区分哪些属于领域层,哪些不属于领域层。

测试先行

测试先行=意图导向编程+用测试表达设计契约

后置的自动化单元测试很难取得成功,原因:

1.上下文丢失;

2.可测性缺乏;

3.情绪和动机。

推荐实践:自动化测试代码先于产品代码完成

image-20200808203758561

开始编写测试——表达意图

image-20200808203858637

契约和手册:TripPlan服务,接收TripPlanCreationCmd,并且返回TripPlanDTO对象,初始状态为CREATED。

开始编写测试——修复错误,完善契约

image-20200808204143708

编写实现代码,实现契约:

image-20200808204318378

image-20200808204343730

增加持久化关注点:

image-20200808204429541

增加REST接口,并在集成环境中测试

image-20200808204456514

image-20200808204546745

image-20200808204559730

覆盖率是一种指示器,也是测试先行的自然结果:

image-20200808204650194

单元测试不是“白盒”测试:

image-20200808204808227

image-20200808205042035

小结:测试先行的收益

1.聚焦于外部行为;

2.自动化测试形成了代码的功能手册;

3.可测性得到了保证;

4.好的可测试性带来了模块化;

5.测试先行容易推动进展;

6.持续建立信心。

持续演进

软件开发中的契约:

image-20200808205639934

legacy code==code without tests

遗留代码,就是没有自动化测试的代码。

自动化测试=自动检查的设计契约。

总结:高效,高质量编码

image-20200808210003956

由外而内,意图导向;

测试先行,定义契约;

渐进认知,持续重构。

软件开发一定要关注设计能力。

image-20200808210241246

DDD-第三课

第三课 从问题空间到方案空间:用领域模型指导软件实现

image-20200726130357011

本讲大纲:

1.从问题空间到实现空间——领域模型和设计质量;

2.从模型到代码——DDD的4个构造块模式;

3.在领域层保证业务完整性——DDD的3个生命周期模式;

4.在产品代码中增加领域层——聚焦核心业务逻辑。

image-20200726130637678

image-20200726130803957

正确的OO:

image-20200726130954289

什么样的设计是好的设计?

Any fool cat write code that a computer can understand. Good programmers write code that humans can understand. ——Martin Fowler, Recactoring

image-20200726131410105

“设计的好坏”和上下文相关

普适性原则:

1.易于理解;

2.易于演进;

3.低开发成本。

image-20200726132002198

问题1:在上图中,有没有哪些对象,它看起来比别的对象重要?再观察地更细一点,这几个对象有什么共同特点。

实体(Entities)

我们会使用唯一地标识符跟踪那些具有重要业务意义地对象。

这些对象通常会随着业务进展产生状态和属性地变更,但是它们代表地业务对象不变。

问题2:在上图中,有没有哪些对象,它的主要作用是描述?

image-20200726132716630

描述类对象地特点是,一旦它发生变化,它就不再是它自己。

值对象(Value Objects)

1.值对象仅仅用来描述特征,所以我们只关心值对象的属性,不关心它有没有唯一标识符;

2.区分实体对象和值对象有助于减少系统的复杂性。

问题3:在右图中,有没有哪些对象,它自身不持有数据,而是表达了某种业务计算逻辑或者业务策略?

image-20200726133237630

服务(Services)

1.一些业务逻辑并不是和领域对象相关,它本身代表了一种商业策略或业务处理过程;

2.服务自身是无状态的。

问题4:有没有哪些对象,它代表了重要的业务事件?

image-20200726133544858

领域事件(Domain Event)

1.领域事件表达了“系统中发生了什么”;

2.领域事件是“领域专家关心的事件”,它们源自于业务活动的结果;

3.领域事件还可增强系统的可回溯性,解耦业务间的复杂关系;

4.领域事件是一种特殊的“值对象”。

image-20200726134142831

问题5:辨析-上车信息中存在“上车点”。图中还有一个“预定义上车点”,这两个对象是什么关系?

1.尽量使用值对象;

2.对于生命周期不一致的数据,慎用关联;

3.转化数据库视角为对象视角;

4.慎用数据库外键。

image-20200726134549751

问题6:发布人、乘车人这些对象,究竟是实体还是值?

应该是值对象。

1.尽量使用值对象;

2.大多数时候不需要完整的实体信息;

3.这类值对象需要保存一个ID;

4.ID来支持必要时获取更多信息或者信息同步。

代码怎么写?

image-20200726140434106

问题域和方案域之间的低表示差距,易于理解,易于演进。

完整复刻,也可能有细微精化。

问题7:图中的对象有很多,请观察它们(实体对象和值对象)是否存在一些“中心“对象?

image-20200726140843234

将实体和值对象划分为聚合并围绕着聚合定义边界。

image-20200726140934530

image-20200726141130378

image-20200726141210817

作为一个整体来定义聚合的属性和不变量,并把其执行责任赋予聚合根或指定的框架机制。

还有其他的问题:

image-20200726141507589

选择一个实体作为每个聚合的根,并仅允许外部对象持有对聚合根的引用。

领域层获得了知识丰富的行为:

image-20200726141734161

聚合(Aggregates)

1.将实体和值对象划分为聚合并围绕着聚合定义边界;

2.作为一个整体来定义聚合的属性和不变量,并把其执行责任赋予聚合根或指定的框架机制;

3.选择一个实体作为每个聚合的根,并仅允许外部对象持有对聚合根的引用。

聚合提升了对象系统的粒度,保证了业务逻辑的完整性,减少了错误产生的概率。

问题8:如果共乘是一个聚合根,共乘应该持有出行计划和支付单吗?

image-20200726142254916

聚合的划分的生命周期一致性原则:生命周期一致性是指聚合边界内的对象,和聚合根之间存在”人身依附“关系。即:如果聚合根消失,聚合内的其他元素都应该同时消失。

聚合的划分的小聚合原则:在不破坏业务逻辑完整性的基础上,小聚合带来更大的灵活性。

工厂(Factories)

1.在设计模式中,工厂的概念是分离构造和使用;

2.在DDD上下文中,聚合需要保证业务一致性,我们应用工厂模式来保证聚合的构造。

image-20200726143337670

资源库(Repositories)

1.资源库是聚合的仓储机制,外部世界通过资源库,而且只能通过资源库来完成对聚合的访问;

2.资源库以聚合的整体管理对象。一个聚合只能有一个资源库对象,那就是以聚合根明明的资源库。除此之外的其他对象,都不应该提供资源库对象;

3.资源库模式不等价于持久化,更不是数据库访问层。

image-20200726144026192

image-20200726144042200

业务完整性

image-20200726144257986

软件开发的本质挑战是复杂性:

1.接口层协议、接口层数据校验、必要的数据补全;

2.应用层的易变的业务逻辑;

3.领域层逻辑及不变形约束;

4.数据持久化、外部数据访问、消息收发。

分成四层:

1.接口层;

2.应用层;

3.领域层;

4.基础设施层。

image-20200726144559418

image-20200726144805336

依赖倒置+分层模型

image-20200726144855683

image-20200726145013816

image-20200726145102395

ajax基本原理及使用

课程重要知识点

1.掌握AJAX技术;

2.掌握JSONP跨域;

3.了解bootstrap;

4.为了学习vue了解下node。

1.AJAX技术:

问题:当用户在地址栏收入一个网址(URL),按下回车到底发生了什么?

image-20200719083924488

回答:当用户在地址栏中输入

image-20200719083948358

总结:是一门前端技术(不是一门语言),客户端可以”悄悄的“

image-20200719085242180

JSONP跨域

image-20200719110927760

image-20200719111247012

域名不同或者端口号不同都是跨域。

node概述

诞生于

image-20200719122945698

DDD-第二课

第二课:准确理解业务需求,持续探索领域模型

平时遇到的问题:我想做领域建模,但是我们的业务人员不重视。。。。

如何才能让大家意识到领域模型的价值?

image-20200718172323912

image-20200718172444511

需求分析的重要性

image-20200718172538066

需求分析的现状:

1.我已经讲了很多遍了,开发就是听不明白。——业务人员真是弱爆了,需求根本说不清楚。

2.能不能不要这么频繁的需求变更呀!——我没有改需求啊,原来就是这么说的呀!

3.能不能不要这么频繁的需求变更呀!——响应变化,需求变更很正常呀!

4.怎么已经开始编码了,咱们的需求还没评审呢!——不先编一点,来不及啊。。。

5.上线了。。。——又遗漏了业务场景。。。

准确理解业务需求,持续探索领域模型

image-20200718173250144

image-20200718173344943

课程大纲:

1.需求分析工具箱——需求分析技术概览;

2.时间风暴简介——用协作的方式进行全局业务探索;

3.静态模型和动态模型——在需求分析中梳理领域模型;

4.实例化需求和领域模型——用领域模型增强实例化需求的效果。

需求分析工具箱:

image-20200718174119957

1.用例分析:结构化的展开和分析繁杂业务场景;

2.实例化需求:解决自然语言的模糊性问题,用例子澄清需求;

3.用户故事:敏捷方法,强调现场客户、需求目标、沟通和确认;

4.用户故事地图:用户场景的全局观、探索发现和迭代规划;

5.事件风暴:面向复杂业务领域,擅长业务场景的挖掘;

6.影响地图:面向业务目标探索不同的解法;

7.其他。

探索和发现、沟通和共识是需求分析的本质

image-20200718204403802

从目标到细节,逐层展开

质疑、猜想、沟通、确认

是协作性的过程,发生在协作空间

使用统一语言,达成一致性共识

用例分析

用例(Use Case)是经典的需求分析方法,起源于90年代Ivar Jacoson的工作,是Rational Unified Process(统一过程)的重要组成部分。

image-20200718204547366

image-20200718204605250

用例解决的核心问题:结构化的分析繁杂的业务场景。

image-20200718204817705

执行者、系统边界、用例

场景、交互

目标、前置条件、后置条件、例外

用户故事地图

用户故事地图(User Story Mapping)是一种敏捷的用户故事可视化方案和协作方法,源自Jeff Patton。

image-20200718205032070

用户故事地图解决的核心问题:在业务目标比较清晰的情况下,探索渐进的业务解法,并据此规划迭代

用户、用户画像、目标

用户旅程、业务流程

骨架故事、替换和扩展场景

规划迭代

image-20200718205324403

事件风暴

事件风暴(Event Stroming)源自Alberto Brandolini,最早兴起于领域驱动设计社区。事件风暴在探索复杂业务领域,发现业务场景方面非常有效。

image-20200718205626745

image-20200718205653301

实例化需求

实例化需求(Specification By Example)是一种需求澄清实践,核心是解决自然语言的歧义性问题,通过例子详述需求,避免沟通歧义。

image-20200718205912011

实例化需求也被称为BDD(Behavior Driven Development)或ATDD(Acceptance Test Driven Development)

它可以被自然地过渡到自动化验收测试,同时由于测试即文档,实例化需求也是实现需求文档的最好方式。

事件风暴简介

点点共乘:

1.无车共乘;

2.顺风车;

3.共享巴士。

如果你是产品经理,你从哪个场景开始?

一个极简场景

用户A发布了一个出行计划,恰好和用户B的出行计划同起点、同终点、相同时间。经系统撮合,二人在约定的会合点见面,共同打车,在抵达后进行了线下结算,行程结束。

请思考:这个场景清晰吗?有没有什么潜在的问题?

事件风暴=事件+风暴

image-20200718211410789

事件:领域事件=业务视角的重要事件

image-20200718211723783

image-20200718212655552

事件风暴的过程中,领域模型同步产出。

静态模型和动态模型

image-20200718212902552

聚焦于功能,收敛于模型

image-20200718212956589

任何概念实体,如果它没有出现在场景中,这个概念实体就没有任何意义;

场景中的任何实体,都必然应该出现在领域模型中,以避免概念遗漏。

image-20200718213126200

用户发布出行计划

image-20200718220220878

image-20200718220252804

系统进行撮合

image-20200718220414096

image-20200718220534997

继续优化

image-20200718220823054

从示例中得到了哪些启发?

统一语言:任何在需求描述中出现的概念,都必须出现在领域模型中。如果需求描述中存在概念之间的关系,领域模型中也必须有这个关系;

领域模型:领域模型是需求分析的自然结果;

探索和发现:沟通过程也是探索和发现的过程。通过讨论,特别是通过显式化领域模型,尝尝能发现模糊的需求,或者新需求的线索,或者需要精确定义的术语。

实例化需求简介

上车点计算策略

image-20200718221511021

请思考:出现在实例化表头上的这些信息,在领域模型中应该有对应吗?

实例化需求

实例化需求的核心是使用例子来描述需求。同时它也是一个从目标出发的需求分析方法。主要手段包括:

1.以终为始:在开始开发之前,定义验收标准,明确需求应该构建成什么样;

2.共同参与:开发、测试、业务共同参与,即时、小批量地澄清需求;

3.构建需求金字塔:基于目标、操作流程、和规则构建需求澄清的金字塔;

4.从实例化需求到验收测试驱动开发:以实例化需求为基础,改变协作的模式和开发过程,实现验收驱动测试开发(Acceptence Test Driven Development)。

总结

image-20200718222628076

image-20200718223002464

image-20200718223036659

DDD-第一课

来自一名一线研发同学的反馈:

开发一直加班加点,但是业务部门还是感觉技术部门还是支撑不了业务的迭代;

上线之后特别担心出故障,总是有一些测试不到的路径,甚至有些问题并不是新修改引起的。

image-20200712172312940

债务严重影响了组织的生产力

1.严格控制代码评审,及时卡住;

2.质量管控,努力测的更完备。

简单的质量管控无法解决问题。

质量不好,做重构,重构问题越来越多。简单的推动重构,重构不会真正发生。

开发效率提升和业务发展要求存在冲突

image-20200712172651240

1.技术支撑商业发展;

2.技术扩展商业边界;

3.技术引领商业创新。

在不良的业务分析、架构设计基础上,推动中台化或微服务,往往会使矛盾凸显。

在云原生的未来,需求分析、架构设计和实现的能力将重新成为基本能力。

可落地的软件开发技术实践

image-20200712173150935

第一课:领域为核心的高效技术实践:从需求分析到业务上线

1.认知是软件开发的核心任务;

2.领域模型是软件开发的核心载体;

3.不要追求“完美”的模型——用协作和演进来探索领域模型;

4.支持协作和演进的实践方法概览。

image-20200712173822265

image-20200712173927211

image-20200712174106055

image-20200712174133120

image-20200712174235193

地心说和日心说

1.地心说也能在一定范围内解释天体运行,甚至通过修修补补,可以让它支持的范围延长很多;

2.日心说是更接近本质的模型,更有竞争力。

映射到软件开发中

无论对业务领域的认知正确与否,在早期支持业务功能总是没问题的。通过修修补补,还能大大延长软件的生命周期和适用性,只不过代价会越来越高昂;

更好的领域模型能带来更简洁优雅的实现,更快捷的知识传播,更容易地支持业务演进。

点点共乘:基于社区的共享出行服务

无车共乘:用户发起拼车业务,说明费用分摊方式、出发地点、到达地点、计划出发时间等信息,邀请其他用户参与,然后共同打出租车;

image-20200712175113445

顺风车:用户发起拼车业务,本人是车主,邀请其他用户参与

image-20200712175458598

社区巴士:运营方根据过往的共乘数据,规划了一些预定义路线,然后发不到社区,让用户选择和自己匹配的线路。

image-20200712175804239

image-20200712175940627

image-20200712180155716

对领域的认知,是一家企业的根本能力和竞争力。

领域模型的基本概念

领域模型:

1.领域模型是概念模型;

2.领域模型描述的是现实世界的实体和他们之间的关系;

3.领域模型是对问题空间的理解。

缺乏领域模型的一些信号:

1.组织中没有关于概念的共识;

2.沟通误解和不必要的需求变更;

3.看似容易支持的业务涉及到系统的很多改动点;

4.架构可理解性和可维护性不足,容易发生意料之外的问题。

领域模型的表示:

image-20200712180749326

高质量领域模型的特征:

1.建立共识;

2.产生洞察;

3.持续演进。

共识的重要性:

image-20200712181205757

大家说一说什么是产品。

共识产生于协作空间:

image-20200712181454352

在白班上可视化领域模型:

image-20200712181543389

建立统一语言:

除非做到统一语言,否则领域模型并不是真正的模型;

一个简单规则:任何在需求描述中出现的概念,都必须出现在领域模型中。如果需要描述中存在概念之间的关系,领域模型中也必须有这个关系。

产生洞察:

image-20200712182058234

产生洞察的三个基本要素:

1.业务人员的直觉;

2.分解和抽象的能力;

3.持续演进的思维方式。

领域模型是深层模型:

有用的模型很少停留在表面层次上。随着对领域和应用的理解逐步加深,我们往往会丢掉那些最初看起来很重要的表面元素,或者切换他们的角度。

这样,一些在开始时不可能发现的巧妙抽象就会浮出水面,而他们恰恰切中问题的要害。

——Eric Evans

我如何才能找到如此的抽象呢?

会不会陷入过度设计呢?

地心说在今天看起来失败了,但是它真的是一个荒谬的理论吗?

image-20200712183640268

image-20200712183744997

持续演进:并不存在所谓“正确”的领域模型,只是说当前的领域模型经过了场景的检验,而且最为优雅。

建立统一语言:

1.将模型作为语言的中心,确保团队在所有的交流活动和代码中坚持使用这种语言。在画图、写文档和说话时也采用这种语言;

2.试着尝试修改模型以及对应的语言表达来消除不自然的地方(相应的也要修改代码,包括模块名、类名和方法等)。

领域模型不是分析阶段的产物,而是软件开发过程中贯穿始终的核心概念

image-20200712184635211

image-20200712184945390

image-20200712185053952

image-20200712185410292

image-20200712185508672

image-20200712185815133

image-20200712185918217

image-20200712190052648

*1在下列现象中,哪些是不够合理的做法?(可多选)

  • 认为领域建模是一个独立的活动,有特定人员完成
  • 领域模型被定义为面向对象方法的一部分
  • 领域模型被认为是软件开发人员的技能
  • 开发人员从代码视角推动领域驱动设计
  • 把领域建模作为一个单独的阶段

*2下列现象中,哪些可能是因为缺乏高质量的领域模型导致的后果?(可多选)

  • 虽然做了中台,但是并没有建立共享的业务能力
  • 做了微服务,却因为服务间的交互过度密集,最后又被迫把微服务合并了
  • 敏捷方法倡导快速交付,一开始看起来挺好,但是后来系统复杂度越来越高,交付速度变得越来越慢
  • 需求沟通经常误解
  • 在编写的代码中,各种逻辑混杂,真正的业务逻辑并不清晰可见,难以维护
  • 对一个业务的开发影响到了一个看似不相关的业务

*3”统一语言“是指(可多选)

  • 业务人员、开发人员和测试人员应该使用同一种概念交流
  • 需求描述、代码和测试用例应该使用领域模型中的概念
  • 其他

*4“好的领域模型来自于持续演进“这句话,你认为(单选)

  • 正确
  • 错误

*5多人协作建模时,更应该选用(单选)

  • 白板
  • 建模软件

*6在领域模型中,下面的符号可能代表(可多选)

img

  • B是一个A
  • B依赖于A
  • 概念A是概念B的抽象
  • B继承自A

*7下列哪些需求分析实践,是你和你的组织中正在采用的?(可多选)

  • 实例化需求
  • 影响地图
  • 事件风暴
  • 用例分析
  • 用户故事
  • 用户故事地图
  • 其他

ALPD方法体系及研发效能36计课程规划

ALPD:Advanced Lean Product Development

image-20200711172557362

大纲:

1.研发效能的挑战;

2.ALPD的方法体系;

3.ALPD的解决方案。

研发效能的挑战

阿里20年技术的发展:

image-20200711173132108

总结为三个过程:

1.技术支撑商业发展;

2.技术扩展商业边界;

3.技术创造新商业。

image-20200711173309788

Tech@Core:

1.云原生;

2.三大中台:数据中台,AI中台,业务中台;

3.上层业务:电商,金融,物流,文娱,数字生活,健康,企业与政务等等。

技术是如何成为商业的内核:

1.支持业务发展;

2.引领业务创新;

3.高效落地实施。

1与2对应ALPD的方法体系,3对应ALPD的解决方案。

image-20200711173733895

业务(发展和创新)驱动的完整效能方法体系

高效和可规模化的效能实施解决方案

10倍交付速度、10倍过程质量、10倍有效价值

ALPD的方法体系

最底层是云原生的IT基础设施,主要包括:微服务化、容器化、自动化和调度与编排。

中间的是业务和产品驱动的精益交付,支持业务发展,主要包括三个方面:

1.领域为核心的技术实践:业务引领的领域建模、微服务架构、契约驱动的软件实现;

2.云原生的工程实践:不可变基础设施、持续交付流水线、可信发布;

3.全链路的精益协作:拉通端与端价值流、对齐业务并快速交付、保障源头和过程质量。

上层是用户目标驱动的精益创新,引领业务创新,主要包括两个方面:

1.业务探索和创新实践:聚焦用户目标、适配阶段的业务目标和策略、加速业务探索、数据分析和调整循环;

2.动态投资组合管理:探索新业务、扩张已验证业务、优化成熟业务、第二曲线创新。

最终实现目标:

1.高绩效、高适应力和持续创新的组织;

2.持续地顺畅高质量交付有效价值。

image-20200711174157885

领域为核心的技术实践,目的是消除业务本质复杂性之外的非必要技术实现成本,主要手段有:

1.业务引领的领域建模;

2.领域驱动的服务架构;

3.契约导向的软件实现。

非必要的技术实现成本举例:

1.需求理解不正确导致的返工成本;

2.架构与领域的不一致,导致改一个小需求需要很多个分散地方的修改,带来了很多额外的协调协作成本。还可能改了一处而另一处没改,带来质量成本;

3.因为架构设计的问题,导致很多已有的功能不能复用,很多重复代码,提高成本,软件维护成本;

4.因为软件设计过度复杂,改动过程中不停的打补丁,软件快速腐化。

image-20200711180019280

image-20200711180109945

1.业务引领的领域建模:从业务场景出发,高效分析需求的同时,识别问题域的本质,构建一致和共同理解的领域模型;

2.领域驱动的服务架构:基于领域模型设计架构和服务,实现从问题域到设计方案高度一致且自然的映射;

3.契约导向的软件实现:以领域模型引导实现,用契约内建质量,并支持实现随问题域持续演进。

超越DDD,以领域为核心的架构和设计方法

why:消除业务本质复杂性之外的一切非必要技术成本;

how:以领域为核心,融合分析、设计和实现过程,保证对问题本质且一致的认知,以及问题域到实现域的映射。

云原生的工程实践

本质的目标是持续、快速、可信的应用发布,主要手段有:

1.不可变基础设施:基于云原生及IaC技术,定义和提供一致和可靠的基础设施,标准化和简化服务的部署及运维;

2.持续交付流水线:以应用为核心,建立端到端的自动流水线,降低变更的发布时间,保障发布过程的可控和一致性,并提供即时有效的反馈;

3.可信发布:建立完整有效的质量、安全、性能等守护体系,并挤成到持续交付流水线,保障发布的可信。

image-20200711182021384

云原生时代的持续交付工程实践

why:持续、快速、可信的应用发布;

how:基于云原生及IaC技术,以应用为核心,建立持续交付流水线,实现快速、可信的发布。

全链路的精益协作

目的是顺畅和快速交付业务需求,主要手段有:

1.拉通端到端的价值流:拉通端到端价值流,改善业务需求的流动效率,缩短端到端的交付周期;

2.对齐业务并快速交付:以业务需求为中心,对齐各个产品、模块和个人的工作,加速业务需求的交付;

3.保障源头和过程质量:保障需求输入的质量,并内建各个环节的过程质量,减少不必要的等待和返工,让需求的流动更加顺畅。

image-20200711183142001

组织视角:资源效率高;

用户视角:流动效率低。

image-20200711183321868

全链路的精益协作实践

why:顺畅快速地交付业务需求

how:拉通端到端的业务价值流,对齐各个产品/团队/个人的交付效率,并内建过程质量。从而,顺畅和快速的交付业务需求,提高交付和响应速度。

持续地顺畅高质量交付业务价值

image-20200711184109882

image-20200712165110857

image-20200712165139952

业务探索和创新实践

目的是高效率地探索有效的价值,主要手段有:

1.识别和聚焦用户目标;

2.适配阶段的业务目标和策略;

3.加速业务探索;

4.数据分析和调整循环。

image-20200711184458084

用户目标为核心的精益创新体系

why:高效率地探索有效的价值

how:识别和聚焦用户目标,定义与产品阶段相适应的业务目标与策略,快速试错,并建立数据反馈和分析调整闭环,确保业务探索和创新的效率和效果。

ALPD的解决方案

从战略及业务到代码以及变更的全链路数字化

组合方案,覆盖业界各类业务和场景

image-20200712165910021

项目驱动的交付模式

在业务层面完成投资决策

基于小项目快速交付和反馈

image-20200712170105372

产品驱动的极致创新模式

对齐业务线和产品线

跨功能和职能的产品团队优先,兼顾平台化重用

基于产品线形成极速业务闭环,灵活创新

image-20200712170246710

战役和业务运营双轮驱动

从业务到代码端到端全局优化,快速响应并形成反馈闭环

适配中台战略,对齐前台和中台节奏,快速交付

image-20200712170425302

总结:

从实践方法到解决方案产品化

image-20200712171012026

image-20200712171038140

认识时间复杂度

常数时间的操作:一个操作如果和数据量没有关系,每次都是 固定时间内完成的操作,叫做常数操作。

时间复杂度为一个算法流程中,常数操作数量的指标。常用O (读作big O)来表示。具体来说,在常数操作数量的表达式中, 只要高阶项,不要低阶项,也不要高阶项的系数,剩下的部分 如果记为f(N),那么时间复杂度为O(f(N))。

评价一个算法流程的好坏,先看时间复杂度的指标,然后再分析不同数据样本下的实际运行时间,也就是常数项时间。