-
《硬核晋升》
重新定义管理
- 举了一个卖柠檬水的摊位的例子。
- 管理的概念与雇用状态无关，而是与“你不再什么都自己做了”这个事实相关。
- 管理的关键：坚信团队会比个人取得的成就更大。但与此同时，也交出了部分掌管权。
-
一名经理的工作是“要让在一起工作的一群人取得更好的成绩”。
- 如何判断一名经理是否优秀：
- 如果说关于这个管理者的角色的定义是要让一起合作的一群人做出更好的成绩，那么一名伟大的管理者管理的团队应该持续交出优异的答卷。
- 看“这个工作团体的工作成果，而不是简单地看他们具体参与的工作。”
- 一半是我的团队的业绩：我们是否实现了我们的目标，也即是否创造了有价值的、易于使用的、设计精良的产品。另一半是我的团队的优势和满意度：我是否招对了人，是否在培养员工，我的下属们在一起工作是否开心且顺利。前一半的评估依据是我的团队现在的成果，后一半的评估依据其实是我们在未来是否可以继续交付卓越的成果。
- 经理们的工作分成三大类：初衷、人员和流程。
- 初衷：你的团队努力想要实现的成果，或者这个也可以被称为“为什么”。保证“你的团队知道成功是指什么，并且每个人都非常渴望获得这样的成功”。
- 例如，你的远大目标是要在每个街口都设立一个柠檬水摊子。你的员工亨利可能觉得你的摊子应该是一个受邻居们喜爱的聚会聊天的场所。那么他就会做一些你觉得不重要或者纯属浪费精力的事情，比如买一些草坪上的座椅或者卖柠檬水的同时试图卖比萨饼。为了防止这些不统一的思维，你需要让他和你的其他雇员了解你真正在意的是什么。
- 人员：你的团队的所有成员都具备成功的条件了吗？他们都有正确的技能吗？他们都积极主动地去做好工作了吗？
- 流程：也就是你的团队如何一起工作。对于管理者来说，重要的流程是用来控制的，包括召开高效的会议，防止未来犯以前一样的错误，为明天做规划，并且培育一个健康的团队文化。
- 初衷：你的团队努力想要实现的成果，或者这个也可以被称为“为什么”。保证“你的团队知道成功是指什么，并且每个人都非常渴望获得这样的成功”。
-
一个伟大的管理者应该不断地问自己，如何通过影响这些杠杆来提高团队的成绩。随着团队的不断扩大，这个经理人本身做具体的工作有多好已经越来越不重要。更重要的是，他对团队的乘数效应有多大。你要做的是改善你团队的初衷、人员和流程，以实现作为一个团体可以实现的最好的表现。
- 是否适合做管理者的三个问题？
- 你觉得实现一个具体目标更激励你，还是扮演一个具体角色更激励你？
- 作为一名经理，判断你的业绩的基础是团队的成绩，所以你的职责是要竭尽全力帮助团队取得成功。
- 适应性是优秀经理人的关键特质。随着团队（人、目标、流程）的变化，你每天做的事情也会相应地变化。
- 如果有一项具体的工作，绝对不想放弃，那么你都会发现个人目标和团队需求可能会产生冲突。
- 你喜欢和别人说话吗？
- 职责中很重要的一部分就是，保证你支持的人可以充分地发挥他们的实力。这就意味着倾听并与团队成员沟通是工作的核心部分。
- 但你不需要成为一个外向的人。
- 你是否擅长处理危机事件？
- 管理就是管人，而每个人都会把他各自独特的经历、动机、希望、恐惧和怪癖带到工作中。
- 你将会面临大量困难的谈话。你可能需要告诉别人，他没有达到其职位所要求的水平。甚至，你可能需要直视对方的眼睛告诉他，他被解雇了。
- 你觉得实现一个具体目标更激励你，还是扮演一个具体角色更激励你？
- 你为什么想要成为管理者？
- 向前一步：
- 职业上升的空间会有天花板，需要进入管理层通道。
- 如果你所在的组织支持“独立贡献者”的成长，好好珍惜你拥有的这个选择。
- 成为决策者：
- 梦想着有一天醒来，他们可以完全掌控自己的命运。
- 如果决策最终被证明是不好的，那么需要承担后果。
- 我愿意，而不是我可以：
- 真心享受管理的工作。
- 向前一步：
- 经理不等于领导力。
- 经理的角色可以被授予或被剥夺的职位，而领导力是拿不走的。
- 领导力呢，它其实是可以带领并影响其他人的具体技能。
- 如果你可以发现一个问题，并且激励大家和你一起来解决这个问题，那么你就是在领导了。
头三个月：4种领导路径
- 4 种领导路径：
- 学徒型：团队在扩大，变成了经理
- 优势：
- 你的领导比你更熟悉你的团队，可以获得更多指导
- 你比较了解团队的情况，可以快速进入角色
- 起步：列举可以改进项，这就是你的方向
- 挑战：建立新的关系
- 扮演教练的角色，可能会有一些让你感觉尴尬的关于个人发展对话
- 为团队结果负责，可能会有一些让别人感觉尴尬的建议
- 从前的小伙伴开始区别对待你，需要重新获得信任
- 平衡：需要平衡作为“独立贡献者”和管理者的工作
- 你的团队有四五个人时，你就应该计划好如何相应缩减你作为“独立贡献者”的责任
- 优势：
- 先驱型：创始人，对成长负责
- 优势：你定义了这项工作，你可以组建自己的团队
- 挑战：作为先驱没有太多获得指导的机会，但可以和同级的人交流
- 新领导型：管理一个已有的团队
- 优势：
- 你有一段时间去适应，别人会放你一马，但要积极主动地开展入职的各项事务
- 你可以重头开始，建立新的管理风格
- 优势：
- 继任型：接替你领导的位置
- 优势：同样比较了解团队的情况，可以快速进入角色
- 起步：参见学徒型
- 挑战：
- 建立新的关系
- 面对团队基于前任经理表现期待的压力
- 做你自己，别人自有别人去做
- 学徒型：团队在扩大，变成了经理
管理一个小团队：正面领导
- 基本原理：发展健康的经理-下属关系，创造一个互相支持的环境。
- 如何让人好好工作
- 解决技能问题
- 帮助下属学习
- 雇佣拥有技能的人
- 解决动机问题
- 缺少做好的标准
- 缺少反馈（奖励惩罚）
- 解决技能问题
- 信任：建立信任关系，得到最真实和及时的反馈，避免错过预警信号
- 信任的表现：
- 被主动汇报工作中遇到的挑战
- 公开的互相“批评”
- 很乐意再次合作
- 信任的表现：
- 努力做人而不是做领导：赢得下属的信任和赢得其他人的信任一样
- 尊重和关心你的下属
- 关心并非无脑站队，而是帮助获取成就感（如放手做事的成就感）
- 尊重是无条件的，而非根据他们的表现来决定
- 我们不仅是在特定时刻为特定团队工作的人，信任关系不仅停留在这一刻
- 花时间来帮助你的下属：一对一对话：
- 建议每个下属每周的一对一不少于30分钟
- 花在小组讨论无法讨论的个人话题上，关注什么能帮助他成功
- 如果对话很愉快却没有记忆点，则需要改进
- 对话的开始：了解情况
- 讨论最优先的事项：对下属来说最重要的结果是什么
- 对你们的目标、愿景、期望达成一致
- 提供反馈：双向的反馈
- 反思进展：心态、目标的变化、最近学了什么、将来的计划
- 对话的继续：
- 识别：什么对下属最重要的，确定今天谈话的方向
- 理解：问题的根源，有什么困难和担心
- 支持：我需要怎么做才能帮助你
- 开诚布公：多直接反馈你的看法，不要让猜
- 承认自己的错误和需要改进的地方
- 人们会忘了你说过做过的，但是不会忘记你给他们的感觉
- 表达“脆弱”有着巨大的力量，通过真实的展现恐惧、误解和不确定而不是掩盖它们可以帮你和下属建立更好的关系
- 尊重和关心你的下属
- 帮助成员发挥各自的优势：
- 人类天生就对坏的事情更敏感，作为一名经理注意力也会被吸引到问题上
- 但每个人都记得有人发现并称赞了你的优势，让你有更多的动力去实现目标
- 对个人：
- 伟大的经理有一个品质：能发现每个人的独特之处并加以利用
- 发现他们的特长，并创造机会，如组织会议、担当导师
- 对团队：
- 不要让团队中最差的人（问题）用尽了你的时间
- 关注团队中的顶尖人才，将资源加倍投入到做的好的“项目”上而不是让每个“项目”都不失败
- 3 * 0.1 === 1 * 0.3
- 团队中最不该容忍的一件事
- 除法效应的人：经常贬低别人，导致别人认为自己比自己想象的差，降低团队其他成员的效率
- 这个人能力很优秀，但失去它的贡献可能也会使得其他人的困难消失
- 不必总是做成事情
- 两个优秀且好心的人也不一定能很好地合作
- 你的“约会对象”很优秀但可能真的不适合你
- 团队成员的离开不代表着你的失败或团队的失败
- 学会放手，直接了当
- 当你花了大量的时间在团队的“问题”上却没有好转时，这种长时间的等待会让团队中的每个人都感到压力
- 你不相信某人在目前的职位上能成功时，有两个选择，帮助他在组织中找到一个新的位置或让他离开
- 要尊重他，直接了当的让他离开，不要公开讨论，也不要认为这是你的管理失败
反馈的艺术
-
反馈是一个领导者的基本工作，无论在进展顺利时还是出状况时，用善良和诚恳的态度表达想法，而非指责。
- 提供好的反馈：
- 明确期待：反馈的过程起始于工作开始前，在行动前应对成功标准达成一致
- 任务导向反馈：
- 具体、明确的根据工作情况的反馈会使得这种反馈不那么针对个人
- 最好的状态是以任务为导向的反馈变成每天的习惯动作
- 行为反馈：
- 从日常的任务反馈中可以了解下属的行为模式和改善项
- 行为反馈更有针对性和深度，且能帮助人们了解他们在旁人眼里的真实状态
- 行为反馈陈述的是对人的看法，斟字酌句，适合一对一进行并结合观察解释为什么会这么想
- 失望源自期待设定错误
- 下属及时的知道了他没有达到你的期待了吗，还是说在落锤的时候才知道？
- 下属知道你对项目过程的期待了吗？
- 是否不知道你想要实时掌握进展，频繁接入而产生了紧张的气氛
- 是否知道哪些是他来决定哪些是你来决定
- 如果你希望及时听到关于项目的问题，就要让大家知道在什么时候说出问题都是安全的
- 带来改善的反馈才是好的
- 反馈的频次：下属对你的期待
- 给我更多的反馈
- 给我跟多关于技能和职业发展的反馈
- 反馈被接受了吗？
- 你说的和他听到的一样吗
- 反馈的方式应该让人感到安全
- 二次确认
- 是否带来了积极地行动：可实施性
- 反馈具体化
- 明确成功的状态
- 建议后续步骤
- 反馈的频次：下属对你的期待
- 反馈要直接了当
- 不要软化你的观点
- 拐弯抹角会显得不真诚
- 插叙插议会使人忽略重点
- 已经做了决定那就不要留出讨论的空间，会显得不真诚
- 反面例子：我担心xxx，xxx比较好，你怎么看
- 同时作为团队负责人，有些决策是你必须要做的
- 不要软化你的观点
管理自己
- 深入了解你的优势、价值观、舒适区、盲点和偏见，然后你才能知道自己的方向
- 冒充者综合征：特别是新手经理感觉会经历这样的感觉，在座的各位中我凭什么在这里？
- 原因：
- 你成为答案的提供者，虽然很多问题你还没有经历过
- 你要经常做以前没做过的事情了！
- 原因：
- 了解自己：
- 自我认知
- 了解你的优势，发挥自己的优势进行管理
- 了解你的劣势
- 通过外界反馈校准自我认知，避免因为不一致将真实的劣势进行管理
- 通过外界反馈，寻求突破和进步，不将其看作考验而是成长的机会（《终身成长》）
- 自我认知
- 了解如何让自己处于最佳状态，根据日常工作需求来调节自己的状态发挥最佳水平
- 正面
- 过去半年最优效率和活力的时间和原因？
- 过去一个月的闪亮时刻和条件？
- 过去一周如何进入的深度思考状？
- 反面
- 最近什么事情让你烦躁？
- 遇到什么样的人让你感到警惕？
- 正面
- 逃出谷底：总有落入谷底的时候
- 放过自己，承认你感觉很糟糕，不要否认这种感觉
- 当一个负面想法开始控制你时，退一步，想想其他可能性
- 利用视觉想象：想象自己没有在谷底的感觉，想象自己完成了一次挑战
- 研究表明，当我们想象自己在做某事时，我们大脑的变化跟我们实际在做这个事的时候的变化是一样的
- 所以也不要想象没发生的坏的情况加剧自己的痛苦
- 向其他人寻求帮助
- 庆祝或纪念谷底中取得的小小的胜利
- 设定边界：不要让这种状态渗透到神获得其他方面，同样也可以在其他方面创造一些进步，获得一些成就感来进行调节
- 加倍刻意学习
- 慷慨的接受反馈
- 向你的经理请教
- 向每个人请教
- 腾出时间反思和设定目标，周期性反思和经验结合会学到更多
开会是个好事情吗
- 什么是好的会议
- 做决策的
- 做出决策
- 让受决策影响的人和制定决策的人参加会议
- 客观提供所有方案，并提供相关的北京信息和团队建议
- 为何种意见提供平等的阐述时间，让大家感到他们的想法被听到了
- 分享信息的
- 使成员感觉到他们学到了有价值的东西
- 清晰、令人难忘的传达关键信息
- 保持观众的注意力
- 提供反馈的
- 让每个人对项目的成功标准达成一致
- 真实的呈现项目的当前状态，进度评估、未来计划
- 清晰设定开放式问题、关键决策和已知问题以获得有用的反馈
- 商定后续计划（包括下次项目、会议的节点）作为结尾
- 产生创意的：创意的产生是需要独立的思考和相互切磋的，二者缺一不可
- 要确保每个参与者有时间单独思考、并将内容写下来
- 每个人的想法都考虑进来
- 通过讨论改进创意
- 以明确的、将创意转化为行动的后续计划作为结尾
- 加强关系的
- 参与者之间创造更好的理解和信任
- 鼓励大家开放、真诚
- 让大家感受到关怀
- 做决策的
- 参会人员没有一个是多余的，那么会议就成功了一半
- 会议的目的是什么
- 哪些人能够促成会议达成好的结果
- 会议前后
- 会前：
- 知识诅咒：主持人很熟悉他们的材料，这种偏差会使得他们很难认识到第一次看到这些内容的人的感受
- 要让参会人提前收到资料、提前处理信息以提高会议效果
- 会后：
- 如果做出了决定，那么应该将其传达给合适的人
- 如果给出了反馈，那么应该采取行动
- 如果产生了想法，那么会议组织者应该明确如何在下一次会议中讨论这个想法
- 会前：
- 创造安全氛围：安全、被鼓励、不带评判的会议氛围更能激发发言
- 明确你想要的行为准则，直接了当的说出来就好
- 根据参会者状态调整会议形式
- 为保证表达充分和均衡采取轮流发言
- 复杂的主题：思考一段时间的即时贴
- 保证平等的说话时间，这是会议主持的责任
- 有些会根本不需要开：如果你觉得自己在反复参加一个价值值得怀疑的会就告诉组织者吧
做好招聘：主动承担录用一个人的风险
- 制定团队年度发展计划，列出所需要的岗位的清单，避免招到因需求急迫却不合适的人
- 招聘的责任
- 你才知道要招什么样的人
- 制定人才搜索策略
- 让面试体验更好
- 告诉应聘者你多需要他
- 招聘像赌博：面试官面试评价和实际工作表现是完全随机混乱的
- 原因：
- 面试时间很短
- 面试过程中存在面试官的个人偏见
- 人会发生变化
- 改进
- 使用过往案例进行参考
- 寻求推荐，增强来源的可靠
- 让多名面试官参与，消除偏见
- 需要充满激情的极力推荐而非平淡的一致同意
- 弱雇佣：大家都觉得还行，那么这个人没啥亮点，带不来太大的价值或改变
- 提前准备面试问题：你要清楚的知道要从面试者这儿了解什么
- 拒绝任何表现出有害行为的人
- 考虑团队的多样性
- 聘用超出所需岗位能力的人，这些人可以在未来帮助你
- 原因：
- 提高招聘效率和培养招聘文化
完成工作计划
-
如何为团队建立有效的流程？
- 创造一个战略
- 制定计划的过程我们可以认清自己的处境
- 当发生紧急情况时，战略可以帮我们调整计划，回到正轨
- 制定计划
- 根据团队的优势制定计划
- 专注于做好几件事，80/20原则，
- 确定谁负责什么，减少分歧和内耗
- 将一个目标分解成更小的目标
- 完美的执行胜过完美的战略
- 执行力的标准
- 任务从重要到不重要依次排列
- 做出决策后，每个人都迅速行动
- 出现新的信息是，通过应急流程检查当前的计划是否需要改变
- 每个任务都有谁和什么时候
- 团队很有韧性，不断学习
- 平衡长期和短期结果
- 确定长期愿景然后倒推工作
- 确保1/3的人完成短期项目、1/3的人完成长期项目、1/3的人完成创新和创意
- 思考每将事情如何和愿景挂钩
- 执行力的标准
- 产品和流程不断优化
领导成长中的团队
- 从小团队到大团队
- 改变：
- 从直接管理到间接管理，你不再能面面俱到必须有所取舍
- 别人会以不同的方式对待你，你不再与每个人都很熟悉，因为这种不熟悉，你们的互动会出现更多的理解偏差
- 不停的切换主题，事情越来越多，时间越来越碎片
- 适应：
- 有所为有所不为，你的时间有限，你最重要的工作是什么
- 掌握通用技能：聘用杰出的领导者、培养自主的团队，建立清晰的愿景、拥有良好的沟通能力
- 改变：
- 任务委派如同盲走钢丝
- 问题：
- 事无巨细的极端：管理风格压抑，团队成员学不到什么，没有机会自己解决问题
- 全面撒手的极端：下属感谢独立的工作机会，一旦进展不顺利则没有任何的规则可言
- 你容易根据反馈矫枉过正、总不能确定自己是否取得了平衡
- 办法：
- 你的时间是有限的，要相信有人愿意负责解决困难的问题，将难题委托给下属，并帮助他处理他需要你做的事情
- 你们的看法应该一致
- 你的工作并不全是帮助下属经理做任何事情
- 如果下属经理不能为团队带来积极的乘数效应则他不合适
- 如果现在他的成长会阻碍愿景或团队发展，他也不合适
- 问题：
- 找人替代你的工作
- 发展优秀的团队意味着你要不断寻找方法来代替你负责你目前的工作
- 每次把工作的一部分给别人的时候，都发现还会有更多的事情等着你去做
营造文化
随着你管理的人越来越多，你将在塑造文化方面发挥更大的作用。
“在脸书，没有任何错误可以怪到别人头上。”
- 进行高难度对话
- 说到做到
- 进行有效激励
-
《领域驱动设计》
在业务第一的原则下，通过对领域层（这个领域层就是业务领域）建模，使得实现和业务互相 1 比 1 真实体现的开发方式？
前言
尽管他们在技术使用方面也值得商榷，但真正挫败他们的是业务逻辑。
错误地将开发人员的角色独立出来，导致建模与实现脱节，因此设计无法反映不断深化的分析。
很多应用程序最主要的复杂性并不在技术上，而是来自领域本身、用户的活动或业务。
领域模型是对知识严格的组织且有选择的抽象，出于某种目的而概括地反映现实。
运用领域模型
先来提一个问题，什么是领域模型？
软件的核心是为其用户解决领域相关的问题的能力，其它特性都要服务于这个基本目的。
- 注：或许可以说模型是与技术无关的有关业务的描述？
消化知识
通过头脑风暴活动创建新的模型或者修改原有的模型对象，并消化理解这些模型对象中的知识。
模型包含各种类型的知识。
不再使用的或不重要的概念被从模型中移除。当一个不需要的概念与一个需要的概念有关联时，则把重要的概念提取到一个新模型中，不重要的概念可以丢弃。
知识消化由开发人员和领域专家组成的团队来共同完成。
高效的领域建模人员是知识的消化者，努力寻找对大量信息有意义的简单视图，只有找到一组适用于所有细节的抽象概念后，才算成功。
领域模型的不断精化迫使开发人员学习重要的业务原理，而不是机械的进行功能开发。
分析员和程序员将自己的知识输入到模型中，模型的组织更严密，抽象更简洁。领域专家也将他们的知识输入到模型中，模型反映了业务的深层次知识，而且真正的业务原则得以抽象。
项目知识零散地分散在很多人的文档中，我们并没意识到不知道的东西究竟有多少。同时，所有项目都会丢失知识。
模型获得的知识远远不只是“发现名词”。业务活动和规则如同所涉及的实体一样，都是领域的核心。
知识消化所产生的模型能够反映出对知识的深层理解。开发人员对模型实现进行重构，以反映出模型的变化，同时，新的知识就被整合到应用程序中。
当我们的建模不再局限于寻找实体和值对象时，我们才能充分吸取知识。
- 注：此章节埋了一个线，运用了整洁代码的方式，将一条过程式的包含业务知识的逻辑封装成了一个可视的策略调用，使业务规则直接可见。但这应该不是领域模型的应用方式吧，我猜？但显而易见的是，更明确的设计确实使得业务规则明确且显得重要，也可以更方便的与不太懂代码的人展示并对齐理解。
随着对领域和应用程序所需要的理解逐渐加深，一些开始不可能发现的巧妙抽象就会渐渐浮出水面，而它们恰恰切中问题要害。
有了更深刻的认识后，我们对航运业务的认识从“集装箱在各个地点之间的传输”转变为“运输责任在各个实体之间的传递”。
交流与语言的使用
要想创建一种灵活的、蕴含丰富知识的设计，需要一种通用的、共享的团队语言，以及对语言不断的试验。
日常讨论所使用的术语与代码中所使用的术语不一致。导致对领域的深刻表述常常稍纵即逝。同时翻译使得沟通不畅，并削弱了知识消化。项目需要一种公共语言，领域模型可以成为这种公共语言的核心，同时将团队沟通与软件实现紧密联系到一起。
通用语言的词汇包括类和主要操作的名称。
- 通用语言：Ubiquitous Language
模型可能缺乏开发人员在代码中所创建的更为微妙和灵活的特性，这要么是因为开发人员认为模型不必具备这些特性，要么是因为编码风格是过程式的，只能隐含的表达领域概念。
通用语言是那些以非代码形式呈现的设计的主要载体，这些包括把整个系统组织在一起的大尺度结构、定义了不同系统和模型之间关系的限界上下文，以及在模型和设计中使用的其他模式。
- 注：感觉很重要，但是不懂，后面再看。
模型驱动设计的构造块
分离领域
我们需要将领域对象与系统中的其他功能分离，这样就能够避免将领域概念和其他只与软件技术相关的概念搞混了。
分层的价值在于每一层都只代表程序中的某以特定方面。大多数的分层架构使用的都是这四个概念层的变体：用户界面层（表示层）、应用层、领域层（或模型层）、基础设施层。虽然项目间会有差异，但是将领域层分离出来才是实现模型驱动设计的关键。
应用层负责对领域对象的行为进行协调。
负责处理基本业务规则的的是领域层，而不是应用层。
各层之间是松散连接的，层与层的依赖关系只能是单向的。上层可以直接使用或操作下层元素，通过调用下层元素的公共接口，保持对下层元素的引用。
最早将用户界面与应用层和领域层相连的模式是 MVC。
- 注：MVC、MVVM、MVX 三层模型中的桥梁部分往往包含了用户界面层的操作逻辑、应用层逻辑和领域层的操作逻辑。是否能通过某种模式再进行一次区分呢？感觉可能也许纯前端领域复杂度也很难到这个程度。
当使用框架时，项目团队应该明确其使用目的：建立一种可以表达领域模型的实现并且用它来解决重要问题。
软件中所表示的模型
- 模型：
- Entity：具有连续性和标识的事物
- Value Object：描述某种状态的属性
- Service：动作和操作，稍稍违背了面向对象的建模传统
对象之间的关联使得建模与实现之间的交互更为复杂。
模型中每个可遍历的关联，软件中都要有相同属性的机制（注：即设计要反映模型将关系）。
设计无需如此直接。（注：在这句话之前，作者举了一个具体的实现方式。所以这句话的意思是，在进行设计时，设计好对应模型的方法即可，不必关注具体，能反映模型即可。）
模式：Entity
很多对象不是通过他们的属性定义的，而是通过连续性和标识定义的。
有时，这样的对象必须与另一个具有不同属性的对象相匹配，有时一个对象必须与具有相同属性的另一个对象区分开。
主要由标识定义的对象被称为 Entity（注：即有一个在系统中不重复的标识方式，如 id、uid 等属性或由一些属性组合判断的方式，这个对象可能是跨系统的，可能在不同系统中属性是不同的，但由标识逻辑却可判断是同一个对象。
- 注：顾名思义，Entity，实体，对应一个由标识区分的具体事物。
Entity 最基本的职责是确保连续性，保持简练是实现这一责任的关键。不要讲注意力集中在属性或行为上，应该摆脱这些细枝末节。
- 抓住 Entity 对象定义的最基本特征，尤其是那些勇于识别、查找或匹配对象的特征。只添加那些对概念至关重要的行为和这些行为所必需的属性。
- 将行为和属性转移到与核心 Entity 关联的其他对象中。
- Entity 往往通过协调其关联对象的操作来完成自己的职责。
模式：Value Object
很多对象没有概念上的标识，它们描述了一个事物的某种特征。
用于描述领域的某个方面而本身没有概念标识的对象称为 Value Object（值对象）。被实例化之后用来表示一些设计元素，对于这些设计元素，我们只关心它们是什么，而不关心它们是谁。
Value Objct 可以是其他对象的集合。
当我们只关心一个模型元素的属性时，应把它归类为 Value Object。我们应该使这个模型元素能够表示出其属性的意义，并为它提供相关功能。Value Object 应该是不可变的。不要为它分配任何标识。
编程语言没有直接支持这些概念上的区别并不说明这些区别没有用处。只是说明我们需要更多的约束机制来确保满足一些重要的规则。命名规则、精心准备的文档和大量讨论都可以强化这些需求。
如果一个 Value 的实现是可变的，那么久不能共享它。无论是否共享 Value Object，在可能的情况下都要将它们设计为不可变的。定义 Value Object 并将其指定为不可变的是一条一般规则。
- 注：具体情况具体分析吧，作为被传递给其它函数或对象的 Value Object 不可变会使变更管理简单。其它场景下在不同语言可能会有更好的可变 Value 的共享模式。也可能是没理解，继续看吧。
模式：Service
在某些情况下，最清楚、最实用的设计会包含一些特殊的操作，这些操作从概念上不属于任何对象。与其把它们强制地归于哪一类，不如顺其自然地在模型中引入一种新的元素，这就是 Service。
有些操作从本质上讲是一些活动或动作，而不是事物，但由于我们的建模范式是对象，因此要想办法将它们划归到对象这个范畴里。
当我们勉强将一个操作放到不符合对象定义的对象中时，这个对象就会产生概念上的混淆，而且会变得很难理解或重构。复杂的操作很容易把一个简单对象搞乱，使对象的角色变得模糊。由于这些操作常常会牵扯到很多领域对象————需要协调这些对象以便使它们工作，而这会产生对所有这些对象的依赖，将那些本来可以独立理解的概念掺杂在一起。
- 注：Service，一个工具箱。
Service，强调的是与其它对象的关系。Service 也可以有抽象而有意义的定义，也应该有定义的职责，而且这种职责以及履行它的接口也应该作为领域模型的一部分来加以定义。操作名称应该来自于通用语言，如果通用语言中没有这个名称，则应该将其引入到通用语言中。参数和结果应该是领域对象。
当领域中某个重要的过程或转换操作不是 Entity 或 Value Object 的自然职责是时，应该在模型中添加一个作为独立接口的操作，并将其声明为 Service。定义接口时要使用模型语言，并确保操作名称是通用语言的术语。此外，应使 Service 成为无状态的。这种无状态是指任何客户都可以使用某个 Service 的任何实例，而不必关心该实例的历史状态。Service 执行时将使用可全局访问的信息，甚至会改变这些全局信息（也就是说，，它可能具有副作用）。但 Service 不保持影响其自身行为的状态。
Service 并不只在领域层中使用，需要区分属于领域层的 Service 和那些属于其它层的 Service，并划分职责，以便将它们明确的区分开。
例如：如果银行应用程序可以把我们的交易进行转换并导出到一个电子表格文件中，以便进行分析，那么这个导出操作就是应用层 Service。“文件格式”在银行领域中是没有意义的，也不涉及业务规则。
模式：Module
Module 的使用有一些技术上的原因，但主要原因却是“认知超载”，Module 为人们提供了两种观察模型的方式，一是可以在 Module 中查看细节，而不会被整个模型淹没，二是观察 Module 之间的关系，而不考虑其内部细节。
- 注：知识边界？忘了看哪本书的时候得出的这个名词，大概是《架构整洁之道》提到边界的时候。一切组织方式都是边界的划分，不同维度有不同维度的划分粒度，从函数、对象、模块、架构组件、服务，都只应该知道什么、只应该负责什么，是一种通用的实践原则。
Module 之间应该是低耦合的，而在 Module 的内部则是高内聚的。一个人一次考虑的事情是有限的（因此才要低耦合）。不连贯的思想和“一锅粥”似的思想同样难于理解（因此才要高内聚）。
低耦合高内聚作为通用的设计原则既适用于各种对象，也适用于 Module。
- 注：Bingo！模块层面：模块间低耦合，模块内模型间高内聚；模型间低耦合，模型内方法高内聚；模型内方法间低耦合，方法内，逻辑分块高内聚。内聚即意味着内部处理同一事物或逻辑，“同一”要看所处的维度，如方法维度就是获取用户登录状态，模型维度就是用户权限，模块维度就是用户行为。低耦合则意味着对单体的内部实现修改不影响同一维度的其它单体的实现。
选择能够描述系统的 Module，并使之包含一个内聚的概念集合，这通常会实现 module 之间的低耦合，但如果效果不理想，则应寻找一种更改模型的方式来消除概念之间的耦合，或者找打一个可作为 Module 基础的概念（这个概念先前可能被忽视了），基于这个概念组织的 Module 可以以一种有意义的方法将元素集中到一起。找到一种低耦合的概念组织方式，从而可以相互独立地理解和分许这些概念。对模型进行精化，直到可以根据高层领域概念对模型进行划分。
Module 的名称应该是通用语言中的术语。Module 及其名称反映出领域的深层知识。
仅仅研究概念关系是不够的，它并不能替代技术措施，这二者是相同问题的不同层次，都是必须要完成的。当必须做出一个折中选择时，务必保证概念清晰，即使这意味着 Module 之间会产生更多的引用，或者改变 Module 偶尔会缠身“涟漪效应”，开发人员只要理解了模型所描述的内容，就可以应付这些问题。
领域模型中的每个概念都应该在实现元素中反映出来。实现中的对象、指针和检索机制必须直接、清楚地映射到模型元素，如果没有做到这一点就要重写代码，或者回头修改模型，或者同时修改代码和模型。不要在领域对象中添加任何与领域对象所表示的概念没有紧密关系的元素。领域对象的职责是表示模型。
建模范式
以上 4 中模式为对象模型提供了构造块，但模型驱动设计并不是说必须将每个模型都建模为对象。一些工具还支持其他的模型范式，如规则引擎。这些其它工具和技术是模型驱动设计的补充，而不是要取而代之。目前主流的范式是对象设计，大多数人都比较容易理解面向对象设计的基本知识。
虽然模型驱动设计不一定是面向对象的，但它确实需要一种富有表达力的模型结构实现，无论是对象、规则还是工作流，都是如此。如果可用工具无法提高表达力，就要重新考虑选择工具。缺乏表达力的实现将削弱各种范式的优势。
- 注：领域模型优先，知识的表达优先，统一性优先。
将非对象元素混合到以面向对象为主的系统中时，要把通用语言作为依靠的基础。即使同居之间没有严格联系，语言使用上的高度一致性也能防止各个设计部分分裂。坚持在多个环境中使用一致的名称，坚持使用通用语言讨论这些名称，将有助于消除两种环境之间的鸿沟。
领域对象的生命周期
主要的挑战有以下两类：在整个生命周期中维护完整性；防止模型陷入管理生命周期复杂性造成的困境中。
采用三种模式解决这些问题：聚合（Aggregate），通过定义清晰的所属关系和边界，并避免混乱、错综复杂的对象关系网来实现模型的内聚；使用工程（Factory）来创建和重建复杂对象和聚合，从而封装它们的内部结构；在生命周期的中间和末尾使用存储库（Repository）来提供查找和检索持久化对象并封装庞大基础设施的手段。
模式：Aggregate
- 注：总的来说是一种提升内聚性，通过减少关联，减少外部引用的边界划分方式，避免对象修改、销毁对外部或业务实现复杂性（竞态）的影响。
具有复杂关联的模型中，要想保证对象更改的一致性是很困难的，不仅互不关联的对象需要遵守一些固定规则，而且紧密关联的各组对象也要遵守一些固定规则。然而，过于谨慎的锁定机制又会导致多个用户之间毫无意义地互相干扰，从而使系统不可用。
- 注：将内聚模型中的非强关联的对象挪出去，可以减少一些竞态锁定导致的冲突或干扰问题。如订单中的商品价格，对订单是通用的，会导致很多订单出现竞态，同时修改频率会比订单低，又不需要实时同步，对确定的订单是没有影响的，就可以挪出内聚。
每个 Aggregate 都有一个根和一个边界。边界定义了 Aggregate 的内部都有什么，根则是 Aggregate 所包含的一个特定 Entity。对 Aggregate 而言，外部对象只可以引用根，而边界内部的对象之间则可以互相引用。
为了实现概念上的 Aggregate 需要对所有事务应用一组规则：
- 根 Entity 具有全局标识，最终负责检查固定规则；
- 根 Entiry 具有全局标识，边界内的 Entity 具有本地标识，这些标识只在 Aggregate 内才是唯一的；
- Aggregate 外部的对象不能引用除根 Entity 之外的任何内部对象；
- 根 Entity 可以把对内部的引用传递给他们（副本、临时引用，非共享的方式）；
- 只有根才能直接通过数据库查询。其它所有对象必须通过遍历关系来发现；
- Aggregate 内部的对象可以保持对其它 Aggregate 根的引用；
- 删除操作必须一次删除 Aggregate 边界之内的所有对象（所以要依赖上面的设计原则，外部对象只对其根 Entity 有引用）；
- 当提交对 Aggregate 边界内部的任何对象的修改时，整个 Aggregate 的所有固定规则都必须被满足。
- 由于根控制访问，因此只能通过根来修改内部对象。
模式：Factory
当创建一个对象或创建整个 Agggregate 时，如果创建工作很复杂，或者暴露了过多的内部结构，则可以使用 Factory 进行封装。
应该将创建复杂对象的实例和 Aggregate 的职责转移给单独的对象，这个对象本身可能没有承担领域模型中的职责，但它仍是领域设计的一部分。
模式：Repository
开发人员可能使用查询（注：查询某些属性）从数据库中提取他们所需的数据，或是直接提取具体的对象，而不是通过 Aggregate 的根来得到这些对象。这样就导致领域逻辑进入查询和客户代码中，而 Entity 和 Value Object 则变成单纯的数据容器。这将导致开发人员简化领域层，最终使模型变得无关紧要。
在所有持久化对象中，有一小部分必须通过基于对象属性的搜索来全局访问。随意的数据库查询会破坏领域对象的封装和 Aggregate，妨碍模型驱动的设计。
为美中需要全局访问的对象类型创建一个对象，这个对象相当于该类型的所有对象在内存中的一个集合的“替身”。通过一个众所周知的全局接口来提供访问。提供添加和删除对象的方法，用这些方法来封装在数据存储中实际插入或删除数据的操作，将实际的存储和查询技术封装起来。将所有对象的存储和访问操作交给 Repository 来操作。
- 注：将于技术相关的代码职责封装进 Repository 中，这个 Repository 应该与一个具体的业务领域对象紧密关联，且不只是与硬件数据库一致的固件 DAO 代码，是负责管理领域生命周期的高层抽象。
Repository 和 Factory 不是冲突的，Repository 内会需要借助 Factory 重建一个已有对象。
- 注：也就是说，Repository 的对象是已经存在的，有重建过程但是同一个概念对象，处在生命周期的中间。
完
后续是一些具体的实践方式，总之还是遵循业务第一、核心业务第一、开发资源向核心业务实现倾斜（而非技术难度），分辨好知识边界的情况下，通过一系列手段实现柔性架构，保证实现的健康成长（真实反馈业务、易维护、易扩展）。
-
《终身成长》- Growth Mindset
-
从区块链到 NFT 到元宇宙
区块链
以比特币白皮书来说，区块链的本质是一个 P2P（点对点）的分布式账本，节点发出交易时需要向周围节点广播，全节点（还有轻节点等，轻节点一般只保存和自己有关的数据）将收到的交易信息写入区块体中，在共识机制（PoW 即挖矿，还有其他如 PoS、DPoS 机制）作用下获取到记账的权限（即认证某些交易数据，向区块链中写入区块的权限），将新区块广播至周围节点，其它节点校验数据有效性和记账权限后根据区块数据同步本地状态，从而达成整个区块网络的状态一致，同时由于新区块头中有前一区块的关联信息，从而使区块之间达成连接，形成区块链。
简单来说，就是网络中所有结点做完全相同的操作在本地维护一个状态一致性的分布式系统。
- 区块链结构：区块 + 哈希链接
- 链：新的区块通过区块间哈希（哈希算法是一种固定输入产生固定输出的算法，可以理解为对输入产生了一个身份ID）关联，区块间通过这种关联成链
- 区块：
- 区块体：
- 区块体的结构往往是一颗树
- 树的叶子结点存储实际数据，即账本信息（如交易信息）等
- 两两向上逐层求得哈希值形成哈希树（即 Merkle Tree 或使用其变种结构）
- 区块头：负责基本功能，一般包含以下部分
- 对前一个区块的哈希求值（仅对前一区块的区块头的内容进行哈希运算）
- 哈希树的根哈希
- 时间戳
- 等
- 区块体：
- 防篡改：
- 单个块：当单个块中的交易信息被某个结点修改后，势必会逐层向上影响至存储在区块头中的哈希树的根哈希，那么就需要修改根哈希才能达成单个区块数据篡改有效性
- 链：如果某个区块中的根哈希被修改，那么对这个区块的区块头进行哈希运算必然会产生新值，和它的下一个区块中的对它的哈希引用的数值对不上，则必然会影响到后续整个链上的所有区块，所以需要修改后续的所有区块才能达成篡改的有效性
- 这种对整个区块链篡改的可行性需要破坏已形成的共识，需要有压制性的优势，理论上在参与者众多的系统中很难达成，从而保证了区块链的防篡改特征
比特币
状态
比特币的节点在本地维护了一个账本叫做 UTXO（Unspent Transaction Output）的状态，即未使用的交易输出，可以简单的理解为某笔未使用的转账输入，用于进行后续转账的转出使用。
运行机制
比特币区块的区块体中以哈希树的结构存储了新发生的每笔交易。
单笔交易的一种协议信息的示例如下：
In: // 表示这次交易使用的资金的来源 Previous tx: f5d8...430901c91 // 资金来源所在交易的哈希 Index: 0 // 资金来源交易哈希中的哪个转出 scriptSig: 3045...798a4 618c...41501 // 对声明的资金来源的解锁脚本，含有签名和公钥 // 可以简单理解为银行卡号和密码 Out: // 表明这次交易的输出 Value: 5000000000 // 金额 scriptPubKey: OP_DUP OP_HASH160 4043...549d OP_EQUALVERIFY OP_CHECKSIG // 锁定脚本，含有对公钥的哈希和一些运算符，使用这笔转出的交易需要在它的 scriptSig 提供可以通过脚本的信息才能解锁 // 可以理解为银行卡号的哈希和一些操作指令- 非对称加密概念科普：
- 公钥、私钥是是成对生成的
- 公钥公开给系统中的其他节点使用，私钥个人保留
- 钱包地址一般是使用公钥进行一系列运算得来的
- 我们不明确区分钱包地址和公钥，可不准确的理解为
- 公钥、钱包：账户账号
- 私钥：账户密码
- 公钥私钥还有一密码学特征：单一钥匙进行加密的数据必定且只能用另一钥匙进行解密
- 加密：发送者使用接受者的公钥对内容加密，只有接受者才能用自己的私钥对内容解密，避免了发送路径上的数据泄露
- 签名验证：更进一步，发出者使用自己的私钥对内容进行签名，将签名和内容发给接受者，接受者使用发送者的公钥对签名解密，发现签名和内容一致，说明发送路径上，内容未被篡改
- 交易信息：每笔交易以之前的交易记录为基础，需要满足输入等于输出（其实是存在差额的，差额会作为节点的手续费）
- 示例：A 账号要支付 6 比特币给 D 账号，则交易数据写为：
- 输入：
- 之前某笔交易的输出（ B 账号支付 2 比特币给 A 账号）
- 之前某笔交易的输出（ C 账号支付 3 比特币给 A 账号）
- 之前某笔交易的输出（ D 账号支付 2 比特币给 A 账号）
- 输出：
- 支付 6 比特币给 D 账号
- 支付 1 比特币给 A 账号
- 输入：
- 特点：
- 需要说明支出的来源
- 说明的资金来源中的金额不能拆分，多出的部分可以通过找零的方式转给自己
- 示例：A 账号要支付 6 比特币给 D 账号，则交易数据写为：
- 交易信息进链：
- 分布式：
- 网络上很多节点进行存储和数据认证
- 发送节点向周围节点广播交易信息
- 每个节点都保存了区块链的完整或部分数据
- 有效性：如某账号同时发送了多条矛盾的交易信息
- 全节点将收到的交易信息进行验证并写入区块
- 验证过程会使用到交易信息中的脚本
- 节点发出的交易信息包含
- 对资金来源的说明
- 对每笔资金来源的解锁信息
- 接收到信息的节点：
- 确认 UTXO：验证资金来源是否存在 UTXO 中，即是否未使用
- 执行脚本：
- 将解锁签名和对应交易输出包含的锁定脚本拼接后以栈结构执行
- 以示例信息为例子，拼接为
[私钥签名, 公钥]（解锁脚本提供）[OP_DUP, OP_HASH160, 公钥哈希, OP_EQUALVERIFY, OP_CHECKSIG]（锁定脚本提供） - 执行大致为：
- 将公钥取出（OP_DUP）
- 进行哈希 160 运算（OP_HASH160）
- 将结果与公钥哈希对比是否相等（OP_EQUALVERIFY）
- 验证签名（OP_CHECKSIG）
- 确权：如何确认 UTXO 的所有权
- 脚本执行过程中的将解锁脚本中公钥哈希后与锁定脚本中公钥哈希对比的过程即是确定所有所有权的操作
- 确认了提供的银行卡账号确实是有这笔余额的账号
- 交易信息防伪：
- 发送节点：
- 对交易信息哈希获得一个摘要
- 用发送节点的私钥对摘要加密生成签名
- 将内容和签名进行广播
- 接收节点：执行
OP_CHECKSIG的过程- 使用发送节点的公钥对签名解密得到摘要 1
- 对内容进行哈希，得到摘要 2
- 摘要 1 等于摘要 2 则公钥、私钥匹配，内容可信
- 即交易信息是解锁这个交易输出的公钥的对应私钥拥有者写的
- 发送节点：
- 节点发出的交易信息包含
- 一致性：网络传输问题，每个节点收到的交易信息可能不同，那么他们验证并写入区块的交易可能不同，如果都要上链则会造成最终生成的区块信息不一致
- PoW：使用共识规则让单位时间内（约10分钟）只有一个节点有合法发布区块的权力，即获得了记账权
- 规则：
- 将新区块的内容（前一个区块头哈希、这个区块的基本信息、新区块的交易信息根哈希）组合成字符串
- 在新区块字符串的末尾加上一个随机数，进行SHA-256，如果结果的二进制前 72 位全是 0 则工作完成，这是一个工作量巨大的碰运气工作
- 随着整体算力的提高会提升难度（增加 0 的数量等）将出块时间稳定在 10 分钟
- 这个过程又因此被称为挖矿，需要大量的算力，进行 PoW 的节点又称为矿工
- 节点收入：
- 比特币网络奖励：节点在出块的时候会写入对自己地址进行 6.25 个比特币输出的奖励交易（Coinbase Newly Generated Coins）信息，此奖励每过 21 万个区块减半，也是比特币的发币方式
- 区块中的交易手续费：区块中所有输入和输出金额的差值，由矿工写给自己
- 分叉：凑巧同时生成了两个区块，则两个块都会并列入链，形成临时分叉，在后续计算中采用最长链原则，废弃追加区块数量少的分叉
- 交易确认：正是因为分叉和废块的存在，所以交易一般需要在继续追加多个区块后才会被确认，比特币一般需要经过 6 个区块的追加才算是相对安全
- 篡改：需要有超高的算力，篡改者的算力需要超过整个网络的算力才能实现篡改，才会使得自己的篡改分叉变成最长链，完成篡改
- 分布式：
总结
- 使用 SHA-256 哈希算法和非对称加密制作数字签名进行防伪
- 执行交易信息中的脚本验证验证签名
- 使用区块链的区块存储比特币交易信息，使用哈希树存储并防止交易数据篡改
- 利用额外的工作规则达成网络一致性（拼算力）
- 将网络奖励和交易手续费支付给矿工节点
以太坊
以太坊黄皮书
https://ethereum.github.io/yellowpaper/paper.pdf
以太坊同样是一个交易驱动的状态机，它支持智能合约，是可编程的区块链，一种去中心化应用的平台。
我们看到比特币有一定的脚本执行能力，但是其脚本比较简单，只支持几种固定的交易协议和脚本命令。以太坊则不同，其是图灵完备的，区块链开发者可在支持范围内自由编程。
结构
区块头
- parentHash：前一区块区块头计算哈希
- ommersHash：叔块哈希
- beneficiary：出块奖励的账户地址
- stateRoot：状态树根哈希
- transactionsRoot：交易树根哈希
- receiptsRoot：收据树根哈希
- logsBloom：数据布隆过滤器
- gasLimit：区块汽油费上限，由矿工们共同维护
- 等
ommersHash
由于以太坊的出块速度较快，它出现临时分叉的可能性也就越高，ommersHash 正是出于抑制分叉的目的设计的，思路如下，被生效区块写入 ommersHash （最多写入两个）的废块也可以获得出块奖励，第一级是 7/8，第二级是 6/8，生效区块写入一个废块也会有 1/32 的奖励。
布隆过滤器
布隆过滤器是一种比较高效但是不太准的查找算法，大致机制如下：
- 提供一批哈希函数
- 将输入映射到阵列的几个点上
- 查询时查询阵列对应的点是否都有值即可
如：
- 存：
- apple 映射到点 1、7、9
- banana 映射到点 1、3、7
- 查：
- orange 映射值为 1、3、9，都有值，则 orange 可能存在
- peach 映射值为 2、3、7，2 无值，则 peach 一定不存在
可以看到布隆过滤器对存在的判断是会误报的，但是不存在的一定不会误报，所以适合大数据量的过滤。
区块体
与比特币不同的是，以太坊的区块体中有三棵树：状态树、交易树、收据树，树的数据会被全节点维护在本地数据库中。
- 状态树：
- 一种变种压缩前缀哈希树（Merkle Patricia Tree，MPT）
- 存储了所有已知（即发生过交易的）的账户的状态
- 外部账户：即钱包地址，无代码，能转账或执行智能合约
- 合约账户：创建合约时生成，存有代码，能被触发执行智能合约
- 账户状态：
- nonce：地址的交易数量或合约数量
- balance：余额
- codeHash：合约账户的代码的哈希，外部账户没有
- storageRoot：账户内容（ 也是一棵 MPT 树）的根哈希
- 新区块只会实际存储发生变化的账户的新状态，未发生变化的会指向之前的区块状态树的对应位置
- 交易树：驱动状态树发生变更，也是 MPT，只保存区块中发生的交易信息
- 消息调用的信息
- 合约账户创建的信息
- 收据树：也是 MPT
- 交易执行过程中的特定信息编码为交易数据，保存在一个索引为键的树中
- 交易过程中创建的日志会构成区块头的 Bloom 过滤器
共识机制
目前以太坊也是使用 PoW （工作量证明）即挖矿的方式确定记账权。
由一个 seed 生成一个小数据集（MB 级别），再由小的数据集生成一个大的数据集（GB 级别大小），在使用区块头和一个 nonce 值求取哈希，映射至大数据集，读取大数据集中目标位置和相邻元素，再哈希，循环 64 次，算出一个哈希和挖矿目标值对比。失败则更换区块头中 nonce 重新计算。
同时以太坊也有像 PoS 机制转换的计划，在以太坊的难度调节机制中存在一个难度因子，此难度因子每 10万个区块会翻一倍，是一个指数级的因子，所以又称为难度炸弹，由于 PoS 机制的上线不顺利，而难度炸弹导致出块速度提升过快，所以以太坊修改了其代码，使得难度因子计算时减去了 300 万个区块，也是由于代码升级导致了以太坊网络的一次硬分叉，还好这次分叉网络节点都进行了代码升级。
智能合约
前面提到，以太坊网络中存在合约账户，账户内存有一段代码，所以智能合约就是按照既定逻辑执行的代码。
调用
外部账户调用合约账户，外部账户发起的合约账户调用也可以调用另一个合约账户。
外部账户调用时，将目标函数和参数写在 data 域中，向合约账户发起交易。
合约调用合约的一种方式：
contract A { event LogCallFoo (string str); function foo (string str) returns (uint) { emit LogCallFoo(str); return 123; } } contract B { uint ua; // callAFooDirectly 的执行返回值 function callAFooDirectly (address addr) public { A a = A(addr); ua = a.foo("call foo directly); // 调用 a 地址的 foo 方法 } }创建和运行
- 智能合约代码编写（solidity 等）完之后，编译成 bytecode
- 创建：外部账户向 0*0 地址发起交易，将代码放在 data 域中
- 智能合约运行在 EVM 中
- 调用智能智能合约的交易将函数和参数写在交易的 data 域中，发布到区块链上后，受到消息的矿工则会按照参数执行代码
- 发起调用的账户需要支付汽油费 GasLimit
- 执行前全额扣除，开始执行，多退少补，不够则状态回滚，汽油费不退
- 执行出错则整体状态回滚，汽油费不退：一个不严谨的例子，智能合约能发起了向 A、B 的转账，如果向 B 的转账出错了，向 A 转账的状态也会回滚
- 每个交易执行之后形成一个收据，存有执行结果等信息
一个例子
这是一个拍卖出价的智能合约：
contract SimpleAuctionV1 { address public beneficiary; // 受益人 uint public auctionEnd; // 结束时间 address public highestBidder; // 当前最高出价地址 mapping(address => unit) bids; // 所有出价 address[] bidders; // 所有出价地址 bool ended; // 是否结束 event HighestBidIncreased(address bidder, uint amount); event AuctionEnded(address winner, unit amount); constructor(uint _biddingTime, address _beneficiary) public { beneficiary = _beneficiary; auctionEnd = now + _biddingTime } } // 参与拍卖的地址向此合约地址发起交易并支付货币 function bid() public payable { require(now <= auctionEnd); require(bids[msg.sender]+msg.value > bids[highestBidder]); // 没出过价则把出价人存起来 if (!(bids[msg.sender] == unit(0))) { bidders.push(msg.sender); } // 如果出价最高则修改当前最高出价人 highestBidder = msg.sender; bids[msg.sender] += msg.value; emit HighestBidIncreased(msg.sender, bins[msg.sender]); } // 拍卖结束 function auctionEnd()public { require(now > auctionEnd); require(!ended); // 把最高出价转给受益人 beneficiary.transfer(bids[highestBidder]); // 给没竞拍成功的人退钱 for (uint i = 0; i< bidders.length; i++) { address bidder = bidders[i]; if (bidder == highestBidder) continue; bidder.transfer(bids[bidder]); } ended = true; emit AuctionEnded(highestBidder, bids[highestBidder]); }- 这里存在一个问题：
beneficiary.transfer，如果 beneficiary 是一个无法接受支付的合约地址（未声明 payable 关键词），那么会导致auctionEnd执行失败，导致所有出价锁在智能合约地址中，永远无法取出 - 除此之外还有重入攻击，即调用的合约账户可能会反过来调用，引发循环执行
Code Is Law。
智能合约的逻辑由代码决定，已发布的合约代码无法修改，如果发布新的代码则会生成另一个合约账户地址，所以就算有 Bug 也无法修改。
The DAO（Decentralized Autonomous Organization）：利用了重入攻击，黑客在自己的合约账户得收款函数中写了向 The DAO 发起调用的代码，使用循环调用的方式，转走了 5000万/1.5亿美元的以太币，约 10% 的以太坊系统总量的以太币，为了弥补对以太坊稳定性的重大影响，经过软分叉修复失败，以太币质押投票，以太坊选择了硬分叉的方式，将 The DAO 中的以太币强行转出，造成了社区分裂，造成以太坊硬分叉为 ETH、ETC。
NFT
从智能合约的例子中也可以看到，智能合约的开发者可以在合约账户的内部维护一个状态树。
其中的一种应用方式就是基于智能合约在区块链的网络内发行 Token，将所有持有人的状态维护在合约账户中。
NFT 正是这样的一种应用，全称为非同质化代币。NFT 的一大特征是，基于区块链的特性公开且防篡改的确定了某地址对某个数字作品的所有权。
一个 ERC721 标准（一种以太坊上发行 NFT 的标准）的 NFT 在区块链的数据示例：
- 地址：0x40468d172cE354d3fAdAb06D0FA53eDdB2F3AA45
- id：6
- tokenURI：https://Opensea-creatures-api.herokuapp.com/api/creature/6）
由于 https 的内容会被修改，tokenURI 一般会用 IPFS 代替（分布式文件存储系统）。这个示例表明某地址拥有编号为 6 的某个物品，其内容为 tokenURI 的内容。
大多数 NFT 的实现上看，在区块链上只是记录了一个作品拥有者的地址、作品的编号、以及这个作品的链接，而作品本身在链下。所以也出现过现实中艺术家的作品被他人拿走铸造成 NFT 出售的情况，所以 NFT 不能解决线下的问题。从理论上讲，NFT 会提供数字资产的流通性，但是不能给物品本身赋予价值。
通过调用智能合约的函数，可以进行 NFT 的转移、交易。所以可以知道，NFT 不单指某一个代币，而是一种代币类型，你也可以通过创建自己的智能合约，发行自己的 NFT 或 NFT 平台。
元宇宙
区块链应该会是元宇宙实现的一个技术，作为可任意复制的数字世界的数字资产进行确权的基础，如现有的 Decentraland 的虚拟土地、创造品的售卖。
同时，对于在数字世界中诞生的虚拟物品，由于不需要解决线下问题，NFT 的应用性应该会更高一些。
其他
- 空块：在部分区块链中，新区块产生后，会先广播区块头再广播区块体，由于区块体数据较大，下载需要时间，部分矿工节点会在收到区块头后就开始挖矿，由于向新区块体中写入的交易信息不能与已有区块冲突或重复，所以为保证在未拿到前一区块信息的情况下的新区块的有效性，不向新区块体中写入实际交易信息（奖励信息除外），从而产生空块。
总结
- 区块链存在交易慢、耗能高诟病，但要结合场景观测，在具体的场景下是比现有的解决方案快的。
- 从理论上讲，基于区块链的 NFT 数字资产交易会提供数字资产的流通性，但是不能给物品本身赋予价值。
- 投资有风险，追逐热点要谨慎。
参考资料
- https://www.bilibili.com/video/BV1Vt411X7JF
- https://www.youtube.com/watch?v=obRzfcvMshM&feature=youtu.be
- https://blog.csdn.net/vigor2323/article/details/122711205
- 区块链结构：区块 + 哈希链接
-
阅读：《认知觉醒》
本书的一大重点是给你的 “我做不到” 给出了强有力的理论支撑！
人的本能潜意识是趋易避难，甚至在这个过程中，本能脑还会对趋易避难的行为给出合理或妥协的解释，使得理智接受。
焦虑也源自求而不得，或是目标设置太高，或是急于求成。
要面对现实，接受这个啥都做不成的自己，因为那是你的本能，然后保持耐心，保持积累和思考，延迟满足。
复利曲线、平台期等都能说明耐心的必然性和必要性。运用理智，将痛苦的进步过程变为本能潜意识的享乐，别把目标设置的太高，不断的突破舒适区边缘的成就感就能带来这种享乐的舒适。
本能潜意识的想法不能作为依据，但可以作为引子。
正确的方法需要：
- 明确的目标，目标越明确，则注意力就越容易集中，惦记的越多越无法行动，逃避模糊也是你的本能，可以提前梳理出第二天要做的事儿。
- 专注，一时只做一件事。
- 有效的反馈。
- 突破舒适区边缘。
如何突破舒适区边缘（能力边界）呢？深度学习和主动反思。
深度学习：
- 表层学习往往会导致学无所获（当然单纯的知识摄入不在此列），从而产生不够投入学的还不够的错误认识，加深焦虑。这里面也有趋易避难本能的作用，单纯的输入比追加一步思考、实践简单多了。懂得百点不如改变一点。
- 构建体系，突然的灵光一闪，偶然的触动都是潜意识的表现，这个时候不要放过这个引子。用理性智慧来进行思考为什么会有这个想法。将这些新鲜的内容和已知的知识或经历联系起来，能力边界一点点的就扩展开了。
- 明确目标、用自己的话理解、教给别人、回顾、总结本质（费曼学习法）。
- 当然，在这个过程中少不了正向反馈，让学习变成令潜意识快乐的事儿。
主动反思：“吾日三省吾身”（可以结合潜意思作答，对反思的问题快速作答，再逐步挖掘。见《零秒思考》）。
-
阅读：《算法》
基础
- 递归
- 递归总有一个最简单的情况，即递归结束。
- 递归调用总是去尝试解决一个规模更小的子问题，至逐渐收敛至最简单的情况。
- 递归的父问题和尝试解决的子问题之间无交集，可以理解为操作部分不同。
- 数据结构：相互之间存在一种或多种特定关系的数据元素的集合，即带“结构”的数据元素的集合
- 存储结构：顺序存储（数组）、链式（链表）存储等
- 数组易查不易写（不要被语言实现迷惑了，在 JavaScript 中，是看不到插入操作时，对后续所有元素的移动的）
- 链表易写不易查（）
- 逻辑结构：线性结构（栈、队列等）、图、二叉树等
- 存储结构：顺序存储（数组）、链式（链表）存储等
-
算法：一组操作的方式
-
研究抽象数据类型的一个重要类型是控制数据结构的复杂度。
- 数据类型
- Bag
- Queue
- Stack
- 算术表达式求值应用：妙呀！
- List
- 算法分析
- 算法耗时
- 每条语句的耗时
- 由计算机性能决定
- 每条语句的频率
- 于是频率就成了关键
- 在一般的频率表达式中一般忽略较小的项，使用~表示，如 N^3/6-N^2/2+N/3，则忽略-N^2/2+N/3
- g(N)~f(N)表示g(N)/f(N)随着N的增大趋近于1，同时将f(N)成为g(N)增长的数量级
- 每条语句的耗时
- 通常的步骤
- 确定输入模型，明确问题规模
- 识别内循环
- 根据内循环中的操作确定成本模型（即算法的基本操作，如常见排序算法内循环中的对数组元素的访问次数）
- 判断这些操作的执行频率，确定成本模型的增长数量级
- 需要注意的是某些大常数系数、内循环外的大量指令可能对增长造成不可忽略的影响
- 常见数量级
- 常数：1
- 对数：logN
- 线性：N
- 线性对数：NlogN
- 平方：N^2
- 立方：N^3
- 指数：a^N
- 内存评估
- 略
- 算法优化
- 完整而详细的定义问题，找出解决问题所必需的基本抽象操作并定义一份API
- 简洁的实现
- 评估实现所能解决的问题的最大规模是否满足预期，是否可改进或另做实现
- 逐步改进实现，通过经验性分析或数学分析验证改进后的效果
- 用更高层次的抽象表示数据结构或算法来设计更高级的改进版本
- 为最坏情况下的性能提供保证时处理普通数据时也要保证普通数据的性能
- 算法耗时
排序
部分排序实现见 demo
- 二叉树性质：
- 组合学性质：高度为 h 的最多只可能有 2^h 个叶子结点，拥有 2^h（1* h 个 2） 个结点的树是完美平衡树。
- 归并排序和快速排序的区别
- 归并排序是局部有序到整体有序。
- 快拍是整体部分有序（一侧小于基准值，一侧大于基准值）到所有局部部分有序（局部够小时则达到局部完全有序），从而使整体完全有序。
- 堆排序
- 优先队列：优先队列适用于不需要全部有序的场景下（如只需要知道队列里最高优先级的任务是什么）
- 基本操作：删除的最大元素、插入元素
- 堆：
- 某个结点的值总是不大于（为最大堆）或不小于（为最小堆）其父结点
- 是一颗完全二叉树
- 堆的根结点是堆有序的二叉树（都有序的二叉树）
- 二叉堆数据结构是优先队列的一种实现方式
- 二叉堆表示法：将堆从上到下，从左到右排进数组（从索引 1 开始），则结点 k 的子结点位置为 2k 和 2k + 1，节点 g 的父结点为 g/2。利用这一特征可以灵活高效实现优先队列
- 算法：
- 上浮 swim：结点由下到上进行堆有序化的过程
- 不停向上交换结点与比他小（最大堆）或比他大（最小堆）的父结点的位置
- 应用：插入新结点时，可将新结点 push 到数组的最后，与 index/2 比较交换位置
- 下沉 sink：结点由上到下进行堆有序化的过程
- 找到所有子节点中比自己大的最大的子节点（最大堆）或比自己小的最小的子节点（最小堆），并与他交换位置
- 应用：队列根结点剔除后，将最后的结点交换至首位，进行下沉操作使得堆重新有序
- 上浮 swim：结点由下到上进行堆有序化的过程
- 利用二叉堆根结点是极值结点（主Key最大或最小的结点）这一特性可以实现排序算法，称之为堆排序算法
- 对数据创建二叉树结构（根据表现那条，数组是堆的表现，即二叉树的表现，所以此步有时可以省略）
- 使用 sink 循环进行堆有序化（小堆有序后，其父结点再次 sink，则更高一层的堆也会有序，由于叶子结点不需要排序，根据表示法来说，最后一个非叶子结点的索引为 length/2，利用这一推论对堆的有序化可以从倒数第二层开始，即 length/2、lenght/2-1、length/2-2 循环至根结点 1，则二叉树堆有序化完成成为堆）
- 将堆的根结点（极值点）提出，对剩余结点组成的失序的二叉树进行重新有序化（参考 sink 的应用），则根结点重新成为极值点
- 循环步骤 3 至所有结点都被提出，则排序完成
- 优先队列：优先队列适用于不需要全部有序的场景下（如只需要知道队列里最高优先级的任务是什么）
- 稳定性：
- 能够保留数组中重复元素的相对位置不变的算法称为稳定的
- 一般需要排序的元素为复杂数据，有时逻辑处理依赖数据的多个键，以键 A 为标准排序后，再以键 B 排序，可能导致拥有相同键 B 的数据，键 A 顺序混乱，引发额外的使用成本
- 规约：将解决问题 B 的方法来解决问题 A
查找
- 二分查找
- 链表实现：写快，读慢
- 数组实现：写慢，读快
- 树实现：
- 二叉查找树：左子树比结点小，右子树比结点大
- 读写速度都居中
- 糟糕！如果树不够平衡，节点偏重于左子树或右子树的化，性能则无法保证，跟二分查找一样！
- 平衡查找树：为了保证平衡性，出现性能的最差情况！相对于赌运气来说，我们还是求稳定！！
- 2-3 树：
- 大致长这样，有两种节点
- 2节点：节点内有 1 个 key，两条链接，和二叉树一样
- 3节点：节点内有 2 个 key，三条链接，左链接小于 key1, 中链接在 key1、key2 之间，右链接在 key2 右侧
- 查找：二叉变三叉的递归，不说了
- 插入：递归！
- 2节点：正常插入
- 3节点：
- 插入变成4节点（即有三个key）
- 将 key2 提升（即4结点拆成一个三个2结点的树）进父结点
- 递归父结点看是不是变成了4节点，继续操作
- 删除
- 大致长这样，有两种节点
- 红黑树：红黑树里节点都是2节点
- 大致长这样：用一个红色的链接来表示 2-3 树中 3 节点的 key1 和 key2 的关系，即将 2-3 树种的 3 节点想想成用一个特殊红链接连接的两个 2 节点，正常链接为黑链接。这样就消除了树种存在两种节点类型，而是使用一个叫 color 的额外属性来表示节点的特殊性，也正是因为这样，红黑树和 2-3 树是等价的
- 性质：
- 任意结点到起任意叶子节点的路径上经过的黑色结点数量相同
- 查找：红黑树在节点表现上就是个二叉树。
- 插入：新插入的节点的 color（链接）一律是红的，但是为了维持平衡性我们需要让红链接方向一致且无连续（有与 2-3 的等价性得来，忘了的话，画个 2-3 树，转换成红黑树看看）
- 消除方向的不一致：旋转
- 旋转：即交换两个节点的父子关系，从而改变链接方向
- 左旋转：b(-a,=d(-c,-e))) 变为 d(=b(a,c),-e)，返回链接中新的父节点
- 右旋转：d(=b(a,c),-e) 变为 b(-a,=d(-c,-e)))，返回链接中新的父节点
- 消除两个连续红链接：变色
- 当父结点的两个子节点之间皆为红链接时（旋转或向只有一个红色左链接子节点的节点中插入右节点产生），即等价于4节点，这时要做的是提升中间节点为父结点（参考 2-3 树），在红黑树种表现为，两个子链接变为黑链接，父结点自身的链接变为红链接。
- 步骤：旋转吧，变色吧，递归直到结束
- 消除方向的不一致：旋转
- 2-3 树：
- 散列表（见算法图解）
- 无顺序信息，易查
- 散列表中重要的是散列函数
- 解决散列碰撞问题：
- 开发寻址法，当前碰撞则找下一个空位，为保证查询速度，需要不断扩张散列表长度
- 拉链法：即以链解决碰撞问题
图
- 图实现的数据结构：
- 邻接表：将每个顶点的所有相邻顶点都保存在该顶点对应元素所指向的一张链表
- 无向图
- 连通性
- 有向图
- 可达性
- 应用：内存管理标记清理的垃圾回收
- 拓扑排序：所有的有向边都从排在前面的顶点指向后面的顶点，即被指向者在后边
- 仅适用于无环图
- 实现使用深度优先的逆后序：递归遍历调用结束后将顶点压入栈
- 强联通：互相可达
- Kosaraju 算法
- 步骤：
- 求出有向图的反向图
- 求出反向图的拓扑排序
- 使用拓扑排序递归顶点
- 则处在同一递归中的顶点在同一强联通分量中
- 证明：
- dfs(G, s) 过程中经过 v，则存在 s -> v，即 s v 联通
- 则在原图遍历时顶点顺序为 s … v，递归 s 时，v 顶点未被递归（已递归的会被排除）
- s、… 、v 为反向图的拓扑顺序，由于 s v 联通，则在反向图中 s -> v
- 反向图中 s -> v 则在原图中 v -> s
- 则原图中 s -> v，v -> s 同时成立，则 s、v 强联通
- 步骤：
- Kosaraju 算法
- 可达性
加权图
- 最小生成树：一颗含有所有顶点的无环联通子图，树中所有边的权重之和最小
- 切分定理，将图分为两部分，跨越两部分的所有边中权重最小的边一定在最小生成树中
- Prim 算法：每条边都是连接当前树和剩下部分的边
- 步骤：
- 将根加入树
- 将新加入顶点的边加入列表
- 将列表中权重最小的边的另一个顶点加入树（即边加入树），并去除已在树中顶点间的边
- 重复2、3
- 有向图：只需要遍历出边即可
- 步骤：
- kruskal 算法：每条边加入的边都是连接未连接的某两部分的边
- 步骤：
- 将所有边排序
- 取列表中权重最小的边
- 边加入树中后不会形成环则将边加入树
- 重复2、3直到有 v-1 条边
- 步骤：
- 最短路径问题
- 适用：
- 耗时为 a 的任务可抽象为 a1->a2 权重为 a 的边
- c 需要在 b 开始后 x 之内开始可抽象为 c -> b 权重为 -x
- 求解最长路径问题可以对权重取反，此时转化为最短路径问题
- 含有负权环的问题是不能求解的，需要检测到负权环并跳出
- 解法：对所有边按照顺序进行“松弛”
- 步骤：
- dist(s -> v) 初始为无穷大（起点到任意顶点为无穷大）
- 判断是否 dist(s -> w) > dist(s -> v) + e(v -> w)
- 是，则 v -> w 为路径中的一个边，edgeTo[w] = v
- 狄克斯特拉算法：按照到顶点的权重值大小松弛边
- 正权边有/无环图
- 负权边的无环图
- 拓扑顺序算法：按照顶点拓扑顺序松弛边
- 无环加权有向图
- 贝尔曼算法（Bellman-Ford）：
- 适用：负权边的有环无负环图
- 实现：
- 通用：以任意顺序松弛所有边 v 遍
- 实际：
- 以起点 s 开始松弛顶点的出边，并修改 edgeTo
- 将所有出边的终点加入队列
- 松弛队列中顶点的出边，并修改 edgeTo
- 如果到顶点 x 的权重变化，则需要将 x 重新加入队列（因为会影响到其他顶点的权重）
- 重复 2、3、4，
- 周期性检查 edgeTo 中是否存在负环，存在则中止
- 步骤：
- 适用：
字符串
KMP
正则
- 递归