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
日志相关的目录
第六课-领域模型和软件资产的持续演进与沉淀
本讲大纲：
1.从资产视角看软件开发；
2.演进式设计是软件开发活动的本质；
3.遗留资产的共存与改进；
4.重构支持设计演进，沉淀领域资产。
开发活动的业务价值和资产价值
为什么强者恒强？
1.资产复用；
2.质量提升；
3.迅捷响应；
4.数据洞察。
资产分类：
1.技术资产；
2.通用领域资产；
3.业务领域资产。
领域资产是最合适的资产粒度。
领域资产的汉堡包隐喻：
关键实践一：划分通用子域，提炼领域资产
关键实践二：用契约描述资产能力和约束
权利和义务
关键实践三：保持领域资产的持续演进
演进式设计：勇气和谦卑
一、敢于在信息不全时做出决策
1.问题域的渐进认知；
2.能力的持续提成；
3.避免过度设计。
二、相信未来一定会变化，为变化做好充分准备
1.业务应用层的自动化测试
2.领域层的自动化测试
a.提供者测试；
b.消费者测试。
三、始终假定自己可能不正确，并使用各种机会检验
统一语言！！！
遗留资产
1.遗留资产充斥技术债务；
2.接口不清晰，边界模糊，副作用未知；
3.代码理解困难，修改可能导致不可预知的副作用；
4.往往缺乏自动化测试。
对待遗留资产的三种态度：
对待遗留资产的第四种态度：
四种基本实践：
1.使用防腐层；
2.在遗留资产上包装并暴露清晰的API；
3.找到遗留资产的接缝，进行扩展；
4.细分遗留资产的边界，进行逐步替换。
使用防腐层：
在遗留资产上包装并暴露API：
找到遗留资产的接缝，进行扩展：
细分遗留资产的边界，进行逐步替换：
1.从价值出发；
2.找到尽可能小的边界；
3.使用自动化测试保护；
4.按领域模型定义接口；
5.编写适配代码；
6.编写新代码，完成替换。
关注点分离是重构的核心要点：
第五课-微服务规划：以领域为中心规划服务
架构反应了重要的决策：
架构定义了系统在其环境中的基本概念或特性，体现在其元素、关系以及其设计和演化的原则。
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
技术演进降低决策难度，聚焦于解决真正的问题
本讲大纲：
1.子域和限界上下文，从问题域出发分而治之；
2.微服务带来了真正的边界；
3.上下文映射、API接口和设计契约。
分而治之在解决复杂问题的同时带来更大价值：
1.各个击破；
2.独立进化；
3.易于复用。
以领域为核心——领域和子域
避免过大的领域模型。用一套模型来描述整个软件系统并不现实
1.简化认知——人并不能同时记住太多概念，刻意地忽略；
2.隔离变化——分而治之，每次处理一个特定方面，隐藏无关信息；
3.聚焦重点——区分那些对业务最重要的因素和次要的因素。
DDD中的相关模式
1.核心域：简化模型。定义一个核心域，并将其与大量支持模型和代码区分开来。
提炼核心域中最有价值和最专业的概念，把核心变小；
将顶尖人才分配到核心域中；
把精力花在核心域上，发现深层模型，确保获得足以实现系统愿景的灵活设计。
2.通用子域：识别那些非核心的领域。
分离通用子域，并把它们放在单独的模块中；
不要让通用子域包含核心域的知识；
考虑分离通用子域的开发人员，最好是使用既有的解决方案。
3.领域愿景陈述：明确核心领域的价值主张。
篇幅不要超过一页；
价值主张需要明确——只提现本领域模型和其他领域具有显著差异化的方面；
尽早完成，并在产生新的洞解时及时解决。
最重要的原则：领域体现的是业务能力
1.能不能用一句话说清目标？
2.是不是有一组内聚的核心概念？
3.有没有可能成为一项独立的业务？
启发式原则：
1.观察业务流程；
2.观察领域模型；
3.观察分析过程。
在业务流程中识别领域
在领域模型中识别领域
演进纬度
领域和子域拆分的要点总结：
1.分而治之是复杂性管理的基本方法，而且有助于隔离变化，提升复用；
2.领域的划分应该从业务视角出发，而不是实现视角；
3.在业务流程分析和领域模型中自然地分解，并保持持续演化的心智；
4.区分核心域和通用域，并在核心域上进行重点投资。
限界上下文（Bounded Context）：最好的工作边界和问题域一致的边界。
限界上线问是什么：限界上下文是一个显式的边界。
观点：如果你在构建全新的系统，请让限界上下文的边界和子域定义保持一致。
用领域模型和统一语言抵御破坏边界的冲动：
障碍1：环境——认知不足和习惯思维；
障碍2：外部——客户压力；
障碍3：自身——缺乏抽象习惯，不注意关注点分离；
不正确的实现破坏了领域边界：
point：评论获得的积分；
isAdminMessage：是否管理员的回复；
memberService：与point是一样的问题。
微服务是一种架构风格
微服务和 子域/限界上下文 紧密相关
以服务的方式实现组件化
围绕业务能力进行组织：
子域和服务规划：以领域作为核心关注点，兼顾非功能性需求，保持持续演化
微服务和限界上下文彼此呼应：
1.领域需要一个边界（限界上下文）；
2.微服务带来了真正的边界；
3.领域需要具有明显的业务价值，并保持持续生长；
4.微服务倡导围绕着业务价值构建服务和团队；
5.在领域层使用领域模型指导服务划分。并不需要为每个构造块定义一个服务，但是构造块提供了服务拆分的良好参考。
上下文映射
共享带来耦合，转化带来损失。
上下文映射的模式：
观点：
如果提供方接口变化带来了问题，但是消费方未能发现，是消费方的责任。
客户供应商：
1.依赖方（可以有多个）是被依赖的客户；
2.依赖方和被依赖方共同开发自动化验收测试，并且加入到被依赖的测试套件中；
3.非常适用于被依赖方的领域模型需要探索的情况。
防腐层ACL
被依赖方对依赖方没有承诺；
被依赖方的领域模型质量不好，或者不符合依赖方的需求，或者依赖方不想和被依赖方捆绑在一起
事件机制和上下文映射
事件是解耦业务领域的非常关键的方法
第四课-高效高质量编码：测试先行和意图导向的编程
本讲大纲：
1.由外而内——发现和形成设计职责；
2.测试先行——表达和实现设计契约；
3.持续演进——契约是设计质量的保证。
从哪里写下第一行代码？
自底向上的编程是很多浪费和麻烦的开始。
一个小游戏背后的故事：
设计是一种信息不完全情况下的决策。
由外而内的编程：
1.一般来说，外层的功能比底层的功能具有更高的确定性；
2.延迟决策到最后时刻，关键信息经常会自然显现；
3.由外而内的编程允许暂时忽略不重要的细节；
4.由外而内的编程——》“意图导向编程”。
意图导向编程就是“想什么就写什么”，用代码来表述你期望的行为。
想象：编码过程中，假设已经有一个理想的方法支持你的工作，你会怎么编写程序？那就这样编写它。
CollisionDetector的具体实现
底层设计一半来说涉及更多细节；由外而内的方式，让底层可以随时被替换。
由外而内、意图导向编程的收益：
1.职责分配是在编码过程中即时完成的，设计和编码真正成为一件事情；
2.代码的可理解性可以得到保证（声明式编程），消除了大多数注释的必要性；
3.以终为始，逐渐导出设计契约；
4.延迟复杂的细节性决策，聚焦于当前阶段的关键行为；
5.利用了IDE的“自动纠错”能力，提升了编码速度。
由外而内编程的2个要素：
1.保持同一个层次的抽象；
2.合理分配职责。
对象的职责在编码过程中自然产生：
所以第一行代码应该从上往下，从功能开始，是最合理的方式，即先写应用层。
创建属性计划的Service：
应用场景驱动，促进领域对象和领域服务的职责持续生长
由外而内，意图导向的编程要点小结：
1.从应用场景出发开始编码；
2.意图导向，描述期望的程序行为，同时完成职责分配；
3.逐层深入，重复上述步骤；
4.涉及领域层对象时，要结合领域对象的职责考虑，并合理区分哪些属于领域层，哪些不属于领域层。
测试先行=意图导向编程+用测试表达设计契约
后置的自动化单元测试很难取得成功，原因：
1.上下文丢失；
2.可测性缺乏；
3.情绪和动机。
推荐实践：自动化测试代码先于产品代码完成
开始编写测试——表达意图
契约和手册：TripPlan服务，接收TripPlanCreationCmd，并且返回TripPlanDTO对象，初始状态为CREATED。
开始编写测试——修复错误，完善契约
编写实现代码，实现契约：
增加持久化关注点：
增加REST接口，并在集成环境中测试
覆盖率是一种指示器，也是测试先行的自然结果：
单元测试不是“白盒”测试：
小结：测试先行的收益
1.聚焦于外部行为；
2.自动化测试形成了代码的功能手册；
3.可测性得到了保证；
4.好的可测试性带来了模块化；
5.测试先行容易推动进展；
6.持续建立信心。
软件开发中的契约：
legacy code==code without tests
遗留代码，就是没有自动化测试的代码。
自动化测试=自动检查的设计契约。
总结：高效，高质量编码
由外而内，意图导向；
测试先行，定义契约；
渐进认知，持续重构。
软件开发一定要关注设计能力。
本讲大纲：
1.从问题空间到实现空间——领域模型和设计质量；
2.从模型到代码——DDD的4个构造块模式；
3.在领域层保证业务完整性——DDD的3个生命周期模式；
4.在产品代码中增加领域层——聚焦核心业务逻辑。
正确的OO：
什么样的设计是好的设计?
Any fool cat write code that a computer can understand. Good programmers write code that humans can understand. ——Martin Fowler, Recactoring
“设计的好坏”和上下文相关
普适性原则：
1.易于理解；
2.易于演进；
3.低开发成本。
问题1：在上图中，有没有哪些对象，它看起来比别的对象重要？再观察地更细一点，这几个对象有什么共同特点。
实体（Entities）
我们会使用唯一地标识符跟踪那些具有重要业务意义地对象。
这些对象通常会随着业务进展产生状态和属性地变更，但是它们代表地业务对象不变。
问题2：在上图中，有没有哪些对象，它的主要作用是描述？
描述类对象地特点是，一旦它发生变化，它就不再是它自己。
值对象（Value Objects）
1.值对象仅仅用来描述特征，所以我们只关心值对象的属性，不关心它有没有唯一标识符；
2.区分实体对象和值对象有助于减少系统的复杂性。
问题3：在右图中，有没有哪些对象，它自身不持有数据，而是表达了某种业务计算逻辑或者业务策略？
服务（Services）
1.一些业务逻辑并不是和领域对象相关，它本身代表了一种商业策略或业务处理过程；
2.服务自身是无状态的。
问题4：有没有哪些对象，它代表了重要的业务事件？
领域事件（Domain Event）
1.领域事件表达了“系统中发生了什么”；
2.领域事件是“领域专家关心的事件”，它们源自于业务活动的结果；
3.领域事件还可增强系统的可回溯性，解耦业务间的复杂关系；
4.领域事件是一种特殊的“值对象”。
问题5：辨析-上车信息中存在“上车点”。图中还有一个“预定义上车点”，这两个对象是什么关系？
1.尽量使用值对象；
2.对于生命周期不一致的数据，慎用关联；
3.转化数据库视角为对象视角；
4.慎用数据库外键。
问题6：发布人、乘车人这些对象，究竟是实体还是值？
应该是值对象。
1.尽量使用值对象；
2.大多数时候不需要完整的实体信息；
3.这类值对象需要保存一个ID；
4.ID来支持必要时获取更多信息或者信息同步。
代码怎么写？
问题域和方案域之间的低表示差距，易于理解，易于演进。
完整复刻，也可能有细微精化。
问题7：图中的对象有很多，请观察它们（实体对象和值对象）是否存在一些“中心“对象？
将实体和值对象划分为聚合并围绕着聚合定义边界。
作为一个整体来定义聚合的属性和不变量，并把其执行责任赋予聚合根或指定的框架机制。
还有其他的问题：
选择一个实体作为每个聚合的根，并仅允许外部对象持有对聚合根的引用。
领域层获得了知识丰富的行为：
聚合（Aggregates）
1.将实体和值对象划分为聚合并围绕着聚合定义边界；
2.作为一个整体来定义聚合的属性和不变量，并把其执行责任赋予聚合根或指定的框架机制；
3.选择一个实体作为每个聚合的根，并仅允许外部对象持有对聚合根的引用。
聚合提升了对象系统的粒度，保证了业务逻辑的完整性，减少了错误产生的概率。
问题8：如果共乘是一个聚合根，共乘应该持有出行计划和支付单吗？
聚合的划分的生命周期一致性原则：生命周期一致性是指聚合边界内的对象，和聚合根之间存在”人身依附“关系。即：如果聚合根消失，聚合内的其他元素都应该同时消失。
聚合的划分的小聚合原则：在不破坏业务逻辑完整性的基础上，小聚合带来更大的灵活性。
工厂（Factories）
1.在设计模式中，工厂的概念是分离构造和使用；
2.在DDD上下文中，聚合需要保证业务一致性，我们应用工厂模式来保证聚合的构造。
资源库（Repositories）
1.资源库是聚合的仓储机制，外部世界通过资源库，而且只能通过资源库来完成对聚合的访问；
2.资源库以聚合的整体管理对象。一个聚合只能有一个资源库对象，那就是以聚合根明明的资源库。除此之外的其他对象，都不应该提供资源库对象；
3.资源库模式不等价于持久化，更不是数据库访问层。
业务完整性
软件开发的本质挑战是复杂性：
1.接口层协议、接口层数据校验、必要的数据补全；
2.应用层的易变的业务逻辑；
3.领域层逻辑及不变形约束；
4.数据持久化、外部数据访问、消息收发。
分成四层：
1.接口层；
2.应用层；
3.领域层；
4.基础设施层。
依赖倒置+分层模型
课程重要知识点
1.掌握AJAX技术；
2.掌握JSONP跨域；
3.了解bootstrap；
4.为了学习vue了解下node。
1.AJAX技术：
问题：当用户在地址栏收入一个网址（URL），按下回车到底发生了什么？
回答：当用户在地址栏中输入
总结：是一门前端技术（不是一门语言），客户端可以”悄悄的“
JSONP跨域
域名不同或者端口号不同都是跨域。
node概述
诞生于
第二课：准确理解业务需求，持续探索领域模型
平时遇到的问题：我想做领域建模，但是我们的业务人员不重视。。。。
如何才能让大家意识到领域模型的价值？
需求分析的重要性
需求分析的现状：
1.我已经讲了很多遍了，开发就是听不明白。——业务人员真是弱爆了，需求根本说不清楚。
2.能不能不要这么频繁的需求变更呀！——我没有改需求啊，原来就是这么说的呀！
3.能不能不要这么频繁的需求变更呀！——响应变化，需求变更很正常呀！
4.怎么已经开始编码了，咱们的需求还没评审呢！——不先编一点，来不及啊。。。
5.上线了。。。——又遗漏了业务场景。。。
准确理解业务需求，持续探索领域模型
课程大纲：
1.需求分析工具箱——需求分析技术概览；
2.时间风暴简介——用协作的方式进行全局业务探索；
3.静态模型和动态模型——在需求分析中梳理领域模型；
4.实例化需求和领域模型——用领域模型增强实例化需求的效果。
需求分析工具箱：
1.用例分析：结构化的展开和分析繁杂业务场景；
2.实例化需求：解决自然语言的模糊性问题，用例子澄清需求；
3.用户故事：敏捷方法，强调现场客户、需求目标、沟通和确认；
4.用户故事地图：用户场景的全局观、探索发现和迭代规划；
5.事件风暴：面向复杂业务领域，擅长业务场景的挖掘；
6.影响地图：面向业务目标探索不同的解法；
7.其他。
探索和发现、沟通和共识是需求分析的本质
从目标到细节，逐层展开
质疑、猜想、沟通、确认
是协作性的过程，发生在协作空间
使用统一语言，达成一致性共识
用例（Use Case）是经典的需求分析方法，起源于90年代Ivar Jacoson的工作，是Rational Unified Process（统一过程）的重要组成部分。
用例解决的核心问题：结构化的分析繁杂的业务场景。
执行者、系统边界、用例
场景、交互
目标、前置条件、后置条件、例外
用户故事地图（User Story Mapping）是一种敏捷的用户故事可视化方案和协作方法，源自Jeff Patton。
用户故事地图解决的核心问题：在业务目标比较清晰的情况下，探索渐进的业务解法，并据此规划迭代
用户、用户画像、目标
用户旅程、业务流程
骨架故事、替换和扩展场景
规划迭代
事件风暴（Event Stroming）源自Alberto Brandolini，最早兴起于领域驱动设计社区。事件风暴在探索复杂业务领域，发现业务场景方面非常有效。
实例化需求（Specification By Example）是一种需求澄清实践，核心是解决自然语言的歧义性问题，通过例子详述需求，避免沟通歧义。
实例化需求也被称为BDD（Behavior Driven Development）或ATDD（Acceptance Test Driven Development）
它可以被自然地过渡到自动化验收测试，同时由于测试即文档，实例化需求也是实现需求文档的最好方式。
点点共乘：
1.无车共乘；
2.顺风车；
3.共享巴士。
如果你是产品经理，你从哪个场景开始？
一个极简场景
用户A发布了一个出行计划，恰好和用户B的出行计划同起点、同终点、相同时间。经系统撮合，二人在约定的会合点见面，共同打车，在抵达后进行了线下结算，行程结束。
请思考：这个场景清晰吗？有没有什么潜在的问题？
事件风暴=事件+风暴
事件：领域事件=业务视角的重要事件
事件风暴的过程中，领域模型同步产出。
聚焦于功能，收敛于模型
任何概念实体，如果它没有出现在场景中，这个概念实体就没有任何意义；
场景中的任何实体，都必然应该出现在领域模型中，以避免概念遗漏。
从示例中得到了哪些启发？
统一语言：任何在需求描述中出现的概念，都必须出现在领域模型中。如果需求描述中存在概念之间的关系，领域模型中也必须有这个关系；
领域模型：领域模型是需求分析的自然结果；
探索和发现：沟通过程也是探索和发现的过程。通过讨论，特别是通过显式化领域模型，尝尝能发现模糊的需求，或者新需求的线索，或者需要精确定义的术语。
上车点计算策略
请思考：出现在实例化表头上的这些信息，在领域模型中应该有对应吗？
实例化需求的核心是使用例子来描述需求。同时它也是一个从目标出发的需求分析方法。主要手段包括：
1.以终为始：在开始开发之前，定义验收标准，明确需求应该构建成什么样；
2.共同参与：开发、测试、业务共同参与，即时、小批量地澄清需求；
3.构建需求金字塔：基于目标、操作流程、和规则构建需求澄清的金字塔；
4.从实例化需求到验收测试驱动开发：以实例化需求为基础，改变协作的模式和开发过程，实现验收驱动测试开发（Acceptence Test Driven Development）。
来自一名一线研发同学的反馈：
开发一直加班加点，但是业务部门还是感觉技术部门还是支撑不了业务的迭代；
上线之后特别担心出故障，总是有一些测试不到的路径，甚至有些问题并不是新修改引起的。
债务严重影响了组织的生产力
1.严格控制代码评审，及时卡住；
2.质量管控，努力测的更完备。
简单的质量管控无法解决问题。
质量不好，做重构，重构问题越来越多。简单的推动重构，重构不会真正发生。
开发效率提升和业务发展要求存在冲突
1.技术支撑商业发展；
2.技术扩展商业边界；
3.技术引领商业创新。
在不良的业务分析、架构设计基础上，推动中台化或微服务，往往会使矛盾凸显。
在云原生的未来，需求分析、架构设计和实现的能力将重新成为基本能力。
1.认知是软件开发的核心任务；
2.领域模型是软件开发的核心载体；
3.不要追求“完美”的模型——用协作和演进来探索领域模型；
4.支持协作和演进的实践方法概览。
1.地心说也能在一定范围内解释天体运行，甚至通过修修补补，可以让它支持的范围延长很多；
2.日心说是更接近本质的模型，更有竞争力。
无论对业务领域的认知正确与否，在早期支持业务功能总是没问题的。通过修修补补，还能大大延长软件的生命周期和适用性，只不过代价会越来越高昂；
更好的领域模型能带来更简洁优雅的实现，更快捷的知识传播，更容易地支持业务演进。
无车共乘：用户发起拼车业务，说明费用分摊方式、出发地点、到达地点、计划出发时间等信息，邀请其他用户参与，然后共同打出租车；
顺风车：用户发起拼车业务，本人是车主，邀请其他用户参与
社区巴士：运营方根据过往的共乘数据，规划了一些预定义路线，然后发不到社区，让用户选择和自己匹配的线路。
对领域的认知，是一家企业的根本能力和竞争力。
领域模型的基本概念
领域模型：
1.领域模型是概念模型；
2.领域模型描述的是现实世界的实体和他们之间的关系；
3.领域模型是对问题空间的理解。
缺乏领域模型的一些信号：
1.组织中没有关于概念的共识；
2.沟通误解和不必要的需求变更；
3.看似容易支持的业务涉及到系统的很多改动点；
4.架构可理解性和可维护性不足，容易发生意料之外的问题。
领域模型的表示：
高质量领域模型的特征：
1.建立共识；
2.产生洞察；
3.持续演进。
共识的重要性：
大家说一说什么是产品。
共识产生于协作空间：
在白班上可视化领域模型：
建立统一语言：
除非做到统一语言，否则领域模型并不是真正的模型；
一个简单规则：任何在需求描述中出现的概念，都必须出现在领域模型中。如果需要描述中存在概念之间的关系，领域模型中也必须有这个关系。
产生洞察：
产生洞察的三个基本要素：
1.业务人员的直觉；
2.分解和抽象的能力；
3.持续演进的思维方式。
领域模型是深层模型：
有用的模型很少停留在表面层次上。随着对领域和应用的理解逐步加深，我们往往会丢掉那些最初看起来很重要的表面元素，或者切换他们的角度。
这样，一些在开始时不可能发现的巧妙抽象就会浮出水面，而他们恰恰切中问题的要害。
——Eric Evans
我如何才能找到如此的抽象呢？
会不会陷入过度设计呢？
地心说在今天看起来失败了，但是它真的是一个荒谬的理论吗？
持续演进：并不存在所谓“正确”的领域模型，只是说当前的领域模型经过了场景的检验，而且最为优雅。
建立统一语言：
1.将模型作为语言的中心，确保团队在所有的交流活动和代码中坚持使用这种语言。在画图、写文档和说话时也采用这种语言；
2.试着尝试修改模型以及对应的语言表达来消除不自然的地方（相应的也要修改代码，包括模块名、类名和方法等）。
领域模型不是分析阶段的产物，而是软件开发过程中贯穿始终的核心概念
*1在下列现象中，哪些是不够合理的做法？(可多选)
*2下列现象中，哪些可能是因为缺乏高质量的领域模型导致的后果？(可多选)
*3”统一语言“是指(可多选)
*4“好的领域模型来自于持续演进“这句话，你认为(单选)
*5多人协作建模时，更应该选用(单选)
*6在领域模型中，下面的符号可能代表(可多选)
*7下列哪些需求分析实践，是你和你的组织中正在采用的？(可多选)
ALPD：Advanced Lean Product Development
大纲：
1.研发效能的挑战；
2.ALPD的方法体系；
3.ALPD的解决方案。
阿里20年技术的发展：
总结为三个过程：
1.技术支撑商业发展；
2.技术扩展商业边界；
3.技术创造新商业。
Tech@Core：
1.云原生；
2.三大中台：数据中台，AI中台，业务中台；
3.上层业务：电商，金融，物流，文娱，数字生活，健康，企业与政务等等。
技术是如何成为商业的内核：
1.支持业务发展；
2.引领业务创新；
3.高效落地实施。
1与2对应ALPD的方法体系，3对应ALPD的解决方案。
业务（发展和创新）驱动的完整效能方法体系
高效和可规模化的效能实施解决方案
10倍交付速度、10倍过程质量、10倍有效价值
最底层是云原生的IT基础设施，主要包括：微服务化、容器化、自动化和调度与编排。
中间的是业务和产品驱动的精益交付，支持业务发展，主要包括三个方面：
1.领域为核心的技术实践：业务引领的领域建模、微服务架构、契约驱动的软件实现；
2.云原生的工程实践：不可变基础设施、持续交付流水线、可信发布；
3.全链路的精益协作：拉通端与端价值流、对齐业务并快速交付、保障源头和过程质量。
上层是用户目标驱动的精益创新，引领业务创新，主要包括两个方面：
1.业务探索和创新实践：聚焦用户目标、适配阶段的业务目标和策略、加速业务探索、数据分析和调整循环；
2.动态投资组合管理：探索新业务、扩张已验证业务、优化成熟业务、第二曲线创新。
最终实现目标：
1.高绩效、高适应力和持续创新的组织；
2.持续地顺畅高质量交付有效价值。
领域为核心的技术实践，目的是消除业务本质复杂性之外的非必要技术实现成本，主要手段有：
1.业务引领的领域建模；
2.领域驱动的服务架构；
3.契约导向的软件实现。
非必要的技术实现成本举例：
1.需求理解不正确导致的返工成本；
2.架构与领域的不一致，导致改一个小需求需要很多个分散地方的修改，带来了很多额外的协调协作成本。还可能改了一处而另一处没改，带来质量成本；
3.因为架构设计的问题，导致很多已有的功能不能复用，很多重复代码，提高成本，软件维护成本；
4.因为软件设计过度复杂，改动过程中不停的打补丁，软件快速腐化。
1.业务引领的领域建模：从业务场景出发，高效分析需求的同时，识别问题域的本质，构建一致和共同理解的领域模型；
2.领域驱动的服务架构：基于领域模型设计架构和服务，实现从问题域到设计方案高度一致且自然的映射；
3.契约导向的软件实现：以领域模型引导实现，用契约内建质量，并支持实现随问题域持续演进。
why：消除业务本质复杂性之外的一切非必要技术成本；
how：以领域为核心，融合分析、设计和实现过程，保证对问题本质且一致的认知，以及问题域到实现域的映射。
本质的目标是持续、快速、可信的应用发布，主要手段有：
1.不可变基础设施：基于云原生及IaC技术，定义和提供一致和可靠的基础设施，标准化和简化服务的部署及运维；
2.持续交付流水线：以应用为核心，建立端到端的自动流水线，降低变更的发布时间，保障发布过程的可控和一致性，并提供即时有效的反馈；
3.可信发布：建立完整有效的质量、安全、性能等守护体系，并挤成到持续交付流水线，保障发布的可信。
why：持续、快速、可信的应用发布；
how：基于云原生及IaC技术，以应用为核心，建立持续交付流水线，实现快速、可信的发布。
目的是顺畅和快速交付业务需求，主要手段有：
1.拉通端到端的价值流：拉通端到端价值流，改善业务需求的流动效率，缩短端到端的交付周期；
2.对齐业务并快速交付：以业务需求为中心，对齐各个产品、模块和个人的工作，加速业务需求的交付；
3.保障源头和过程质量：保障需求输入的质量，并内建各个环节的过程质量，减少不必要的等待和返工，让需求的流动更加顺畅。
组织视角：资源效率高；
用户视角：流动效率低。
why：顺畅快速地交付业务需求
how：拉通端到端的业务价值流，对齐各个产品/团队/个人的交付效率，并内建过程质量。从而，顺畅和快速的交付业务需求，提高交付和响应速度。
目的是高效率地探索有效的价值，主要手段有：
1.识别和聚焦用户目标；
2.适配阶段的业务目标和策略；
3.加速业务探索；
4.数据分析和调整循环。
why：高效率地探索有效的价值
how：识别和聚焦用户目标，定义与产品阶段相适应的业务目标与策略，快速试错，并建立数据反馈和分析调整闭环，确保业务探索和创新的效率和效果。
组合方案，覆盖业界各类业务和场景
在业务层面完成投资决策
基于小项目快速交付和反馈
对齐业务线和产品线
跨功能和职能的产品团队优先，兼顾平台化重用
基于产品线形成极速业务闭环，灵活创新
从业务到代码端到端全局优化，快速响应并形成反馈闭环
适配中台战略，对齐前台和中台节奏，快速交付
总结：
从实践方法到解决方案产品化
常数时间的操作:一个操作如果和数据量没有关系，每次都是 固定时间内完成的操作，叫做常数操作。
时间复杂度为一个算法流程中，常数操作数量的指标。常用O (读作big O)来表示。具体来说，在常数操作数量的表达式中， 只要高阶项，不要低阶项，也不要高阶项的系数，剩下的部分 如果记为f(N)，那么时间复杂度为O(f(N))。
评价一个算法流程的好坏，先看时间复杂度的指标，然后再分析不同数据样本下的实际运行时间，也就是常数项时间。
