八叉说内容提炼记录

统一语言的坏味道：
dao对于ddd来说是坏味道，因为它是纯技术层面数据访问内容。使用它，说明程序员放弃了对于业务逻辑领域归属的考量——不应该让业务去找技术归属。repository比dao好一些，它应该存在于聚合根上，如果确实考虑了业务对于数据的操作的封装，它就是好的。如果仍然对于数据库对象各产生一个操作对象，还是仅仅对dao一个重命名，没有意义。
业务的数据逻辑可以拆分为对象的逻辑和集合的逻辑，引入集合逻辑对象，有助于明确业务逻辑，减少坏味道。
低代码是行业毒瘤：
形式逻辑和历史事实证明，让不懂代码的人写代码的想法是错的。图灵邱奇定律：没有一个模型可以跨越另一个模型提供额外的能力。图灵完备意味着提供完整能力，非程序员无法跨越编程知识而掌握，非图灵完备意味着功能缺失。非程序员不能借助一种新语言跨越编码细节，实现程序编写。最终还是会落在程序员头上。
民主化编程：
企业中有一些员工的工作可以被数字化规范起来，但是如果投入开发团队没有商业收益，对于这一部分情况，低代码平台是有效的，这一部分员工可以开发低代码功能给自己用，把自己工作内容自动化。当前企业发展中，产生了许多可复用的能力，包装成了微服务，而对微服务能力的整合，又能做一些全新的事情，这一部分有些就会被低代码平台的开发利用起来，给员工自己使用。所以低代码平台可以作为企业应用需求的孵化器，通用性强的需求，可以派发开发资源统一的整合。为了节约成本直接用低代码平台招烂开发，或者用它直接开发出产品化内容，都是畸形的、不应出现的。
围绕现金日记账和KPI是业务建模最有效的方法：
传统的快速了解一家企业的业务的通用方法就是通过看它的账目，放在今天也是存在有效性的办法。对企业业务建模需要把握住两点，一个是价值流，一个是组织架构，而现金日记账是还原现金流最基础的技术，它就体现价值流。现金流就会反映收入支出，追溯这些内容可以得到领域事件。收入一笔钱一定是企业提供了某些服务给客户，它体现了企业的合约义务和履约行为。收入一笔钱一定是获得某些服务，同样可以追溯出合约权利和履约行为。这是一个公司业务合法合规的底线，所以一定存在。有些业务内容存在，但是无法直接关联到现金日记账，这样的业务要看与KPI的关联。KPI反映的是企业对员工的管理目标，相当于企业与员工的合约。
测试金字塔和测试策略：
系统需要两类测试：发现问题的测试和定位问题的测试。功能测试覆盖代码量大，主要用于发现问题，单元测试、组件测试和集成测试覆盖代码量小，用于定位问题。单元测试本身一般已经不能验证功能是否正确，需要构造等效测试，把功能测试等效为一系列单元测试，使得它能帮你定位问题。所以测试金字塔只是一种实现策略的结论，本质上，你要思考你的测试策略能不能帮你达到上述目的，怎样帮你达到目的，怎么实现效率最高，来具体设计测试策略。
六边形架构还值得选择么：
六边形架构核心价值是通过适配器桥接，定义边界输入输出，把业务和技术的内容分离，来保持技术架构改变时，业务可以不变。但实际上需求变化比技术架构变化要快的多。六边形架构本身是基于单体架构假设的一种设计，当时认为是变化，需要隔离的部分，今天已经不再是变化的了。考虑架构时，应当先从部署结构和物理形态考虑：今天的部署和当时非常不同，所以六边形架构基于过时设计，不能适应今天的情况。只有从最基本的原理思考，怎样隔离和适应变化，才是有效的架构设计的思路。
面向对象仍然是默认的选项么：
面向对象的前提是数据完备于内存中，这种情况下，把数据模型和数据处理的逻辑放在一起是合适的实现。后来出现数据库之后，数据不再是完备的，完整的面向对象就不存在，自然而然的出现贫血模型。seviceless的架构完全把逻辑和数据剥离，而hadoop则倒置为代码迁移给数据源去执行。这些新兴事物提示我们，面向对象不应该被看作一种默认的实现。从restful接口外部看，无论是否是面向对象的设计，都是无关的。
TDD和瀑布没什么区别：
瀑布需要完备的文档，在纸面预演开发过程，完备的思考和解决可能遇到的问题。TDD将需求拆分成任务，每个任务大约15min左右，都是用测试用例表达的。在这一过程中澄清需求和发现技术能力缺失，去尝试补充能力。殊途同归，都是软件开发的良好实践。
好的showcase：
好的showcase就是没有惊喜，也没有意外的。你可以先通过与showcase各方私下沟通，趟平问题。可能有人挑战，但要保证基本盘。最好的是让一部分业务方回答其他业务方的问题。showcase在敏捷中非常重要，没有通过的情况客户可以不付钱。showcase可以弥补客户对敏捷项目的当前状态把握的缺失。showcase不需要开发人员发光，可以把舞台给客户和领导，让他们多表现。
为什么说《领域驱动设计》已经过时了：
领域驱动设计通过领域建模解决业务复杂度问题。根本复杂度来自业务，进一步看，来自运维模式和业务模式变化的时候，it如何去跟随。而领域驱动设计没有这方面内容，它没有对变化点建模和描述的内容。对于一个企业来说，用户渠道变化最快，运维模式次之，业务模式最次。在不同的速率上，系统稳定的程度不同，适用于ddd的程度就不同。对于相对稳定的系统，ddd的建模是有效的，对于变化速率高的部分，ddd建模会额外的增加成本和复杂程度，而它本身在付出高成本后旋即被抛弃，适用ddd的策略会十分荒唐。
中台三问：
中台与平台不同在于，平台是对业务流程的封装，抽象的是个别能力和技术能力。中台试图抽象业务模式或业务流程，在不同前台需求中抽象公共服务模块，避免成为大后台。它需要开发者思考和抽象企业依靠什么做业务，什么样的业务在驱动各个模块运转。
1.如何避免中台成为一个单点，以至于中台瘫痪导致系统瘫痪
中台没有必要按单点部署，也不需要所有前台访问相同实例。完全可以是相同的逻辑，分离的部署。复用的只是抽象的能力。
2.中台实现前台的定制需求与中台实现通用需求的矛盾如何解决
中台开发者思维的出发点是我是什么，而非你是什么，你有什么需求需要我满足。观察前台业务的目的是给自己找到主体性。
3.中台在企业结构中，会给it与业务的合作带来怎样的冲击和影响
康威定律：线型系统和线型组织架构间有潜在的异质同态特性。成立服务中台的组织架构会带来中台和前台的张力，但这不是问题，会帮助中台服务找到边界，达到平衡。
微服务拆分粒度：
对于单体应用，业务高峰到来时，各个业务部分有不同的弹性需要，单体的扩展不能支持这一点。以部署需要为微服务边界拆分，符合微服务设计的最初目的。微服务架构是在云原生时代，把弹性放在核心地位的架构。有时也基于发布周期解耦的考量，会拆分微服务。
对于通常被认为的微服务能提供服务重用功能来说，实际上不存在计算的重用的瓶颈，往往带有数据和逻辑的内容是需要重用的。所以无服务并不是微服务的趋势，它们是不同的。复用是一个潜在的收益，而非明确的收益，不应该以复用作为拆分微服务的原因。
基于细胞特化的架构思想，也可以制造相同的单体部署，通过其所处位置的不同，发挥不同的功能，并且通过定制网关解决弹性的问题。这样做方便功能的延续和复用，解决一部分cap和代码架构层面遇到的困难。也侧面说明了，微服务不是越微越好。
领域逻辑与运维逻辑：
业务逻辑分为领域逻辑和运维逻辑，领域逻辑是通用的，与具体公司的运作无关的，与所处行业地区等有关。企业谈业务需求一般没有领域概念，而是提软件的运维逻辑。所以市场上软件定制也有两个思路，一个是要求企业适应软件的运维逻辑，做对应组织调整；一个是软件存在通用功能，定制运维逻辑，也会要求企业适应，但程度会低。今天的环境下，无法抛开运维逻辑谈领域逻辑，设计软件的时候要多做相关思考。
DDD遇到业务系统，还是最佳实践么：
领域的复杂度和业务的复杂度不是同一维度的问题，DDD提出时，系统多是在领域的维度复杂，目前的多数系统主要复杂度在业务方面。对业务的抽象会体现在中台，而不是领域中。所以当遇到业务复杂度高的系统，不应当首选DDD，直接开发会更好。
软件开发管理为什么这么难：
主要是因为惯性的才用了软件行业发展之前的管理实践和方法，没有认识到软件管理的实质。
1.团队中存在角色和分工的原因：
出现社会分工会产生职业角色，在充分商业交换的社会，职业角色之间的比较优势天然的提高整个社会的效率。本质上是一个资源重新配置的问题，但前提是存在对产出结果物的交换。
2.软件开发和交付的过程实质：
实质是知识生产、消费和传递。从业务方，到需求分析者，到开发者，实际这样看待问题比当做生产产品的过程更接近实质。生产产品的分工要求知识壁垒越高，效率越高；而开发之间知识壁垒越高，效率越低。比如DDD就是在用统一语言降低知识壁垒。
划分知识边界提高团队效率：
基于上一个问题的回答，分工产生了专业性，想要提高团队的效率，需要能产出物能够黑盒复用——不需要了解内部细节，这样提高知识壁垒增加效率。所以管理者要思考能不能在团队内找到黑盒复用的知识背景。比如DDD中限界上下文拆分，而不是横向分层——展示层，服务层，持久层然后团队内分配。因为分层后各层次间仍然是白盒的，知识不但要学习，还要沟通同步。只有在知识边界的划分团队职责，才能带来效率提升。这也同样适用于微服务划分时候的思考，虽然按照业务划分是可以的，但划分后有没有获得微服务划分的好处，有没有促进黑盒复用。而在一个知识边界之内，消除知识壁垒有利于提高效率。需求分析者写需求，如果没有开发者消费，他的效率是0。在知识边界内，应当通过知识传递的效率来衡量团队的效率。
云计算是一个远远被低估的技术：
云计算兴起深刻改变了软件，但仍然是一个远远被低估的技术，因为它挑战了我们的概念和想法。不同团队有不同的研发流程，很难统一成一致的，根本原因是资源不易获得。软件团队会为了适应环境而改变交付节奏，流程差异本质是环境差异。云计算兴起后，资源变得易获得，我们可以用变化的环境统一流程。首先受到挑战的是devops流水线，它的核心思想是代码在交付流程之间流动，它的前提是环境不变，代码迁移。原因在于环境不易获得，代码便宜。目前来看，流水线是否还是最佳实践，还需要时间检验。与它对应的一种环境提升的机制也已经走进了大家的视野，它对于dev环境的制品直接提升为uat来完成开发流程的流转。
无法被996管理的知识工作者：
根据泰勒的观点，传统的管理关注的是对产出物和工作时间的管理。软件开发中，宏观产出有效性是上层制定计划时决定的，而微观产出的有效性都是由消费侧决定，管理者想实现有效管理比较困难，验证工作产出的效果的反馈周期太长。管理工作内容对于知识工作者不适用，因为大部分工作是在头脑中，开始动手的部分是小部分的工作。所以管理工作时间是管理者唯一可行的管理手段。本质上，996蔚然成风的原因在于没有好的方法论管理知识工作者。
有一种现存的实践是通过缩短产出物验证的时间周期，来通过管理产出物。往往要求代码更快速上线，和更快速的处理线上问题。这就是所谓互联网研发模式。由于无法管理工作内容，企业往往采取胜任力培养的方法，让员工更有效率。这样，管理产出变为缩短开发周期，管理内容变为胜任力、能力、学习力培养，管理实践转化为996，形成了新的管理三角。这样管理者有更多的管理空间，而不是只能通过996解决问题。
端到端交付：
最初对于敏捷开发，前后端分离是反模式，因为没有独立知识边界，产出物不是独立的交付物，会产生额外的知识同步的成本。由于知识结构的发展，后端不再是行业内认识的数据库表，而是发展为微服务，它代表企业的能力。能力相对稳定，而用户体验和业务会变化较快。通过能力构建知识边界，企业可以形成闭合的明确的知识边界，形成端到端交付。通过bff形成对前端的端到端交付。由于行业内出现大量正确划分的前后端的端到端交付，所以这个内容成为正向的良好的开发模式。所以具体的团队的前后端分离做得对不对，主要是看知识边界的现状，产生了怎样的端到端交付。
同样道理，渐进式增强也是在产生独立知识边界基础上，分离用户交互和数据的开发管理实践。
为什么绝大多数组织都是金字塔结构：
泰勒实验的传统观点认为，管理者应该有两种，一种决定什么是对的，一种决定怎么做事情是有效率的。第一种人很少，第二种人较多，最多的是具体工作执行的人。这种结构叫金字塔结构，我们认为这是一种单纯官僚结构。因为它试图通过标准化流程和解决方案解决问题，它擅长在不需要创新力，只有已知问题的企业中搞管理。这种管理模式的假设就是需要处理的问题绝大部分是已经发生过的、有预案的问题。
从单纯官僚组织到技术官僚组织：
单纯性官僚组织起来的企业会存在大企业病，表现的僵化。当行业的当前情况已经被企业理解——企业认知能力较高，单纯性官僚的组织是没有问题的。当行业产生变化，且变化没有被企业掌握时——企业认知能力较低，单纯性关联组织就有问题。这时需要技术官僚组织来管理，管理者本身是技术专家，他能吸取行业内已有技术方案，解决较复杂的问题。这意味着企业定位它要面对的管理问题主要不是已有预案的问题，而是主要面对新的问题，但可以通过对已存在技术方案的了解来解决问题。
组织架构与认知模型：

认知模型中，复杂度：混沌>复合>复杂>明显。不同的时期和情况，企业会面临不同的问题，对企业的提出不同的挑战和要求。一般情况下，企业应建立应对复杂情况的组织架构。回顾可以帮助企业把复合降级为复杂问题。回顾可以帮助组织认识哪些做得对，哪些做得不对。标准化和自动化可以帮助企业把复杂问题转化为明显问题。在维护和消亡期，绝大多数问题都是明显问题，单纯官僚组织可以应对。
估点的正确姿势：
当估点追求准确的时候，会发现要得出某一个结果，需要前置条件一个或多个都满足，而没有满足时，估点就不成立。这样的估点是脆弱的，依据它形成的方案也是脆弱的，所以有可能得到精准而脆弱的计划，也可能得到强壮而不准确的计划，后者显然更有价值。
管理者要求估点准确，实际要求的是两个方面：1.单位时间内最大的输出，即确保员工有效的利用了时间。2.在时间的下限内完成任务，保证功能成本的同时节约了管理成本。所以管理者可以采取这三个方案：1.不估点，以故事的个数作为工作量，这是基于实际工程经验——同一个团队点数和故事数基本是线性的。2.确认下限，算出一个故事需要的平均时间，要求开发者提供可以完成的故事的个数，如果超过风险控制的比例，则拆分故事到更细的程度——平均时间会减小，再次要求开发者估算可以单位完成的比例，直到比例达标，认为风险可控。3.上限管理，关注未在上限时间内完成的故事，进行总结归因，一般只有两种原因，人员能力不足或需求理解错误。再针对这两种情况进行干预和改进。
关于小程序端的问题：
1.有的公司把小程序端做成一个轻量级的app端，和app端功能和界面基本一致，而有的公司把小程序做成用完即抛的只有一个阶段功能的工具，哪种合适：
要从用户需求的体验和场景的角度出发去思考，比如用户去便利店买东西，如果是一个过路用户，只需要一个支付工具即可，不需要会员、积分、活动等长期维持和交互的功能，对应这种情况的小程序就是工具化的。如果是店里全是小区的长期用户，就需要一些这样的功能和生态，就不再是一个工具化的应用。
2.小程序和其他端怎样紧密结合：
思考用户体验的连续性。现在对于用户在使用场景变化的情况下，保持内容连续性的相关产品体验有很多成功的例子。比如用户看视频，要上车了转化为音频继续播放。多端之间应该能给用户体验带来延续，下游的体验一定需要能接续上。另一种思维是存在小程序阵列，形成一系列差异化入口提供差异化的体验，它们之间可以有不同的流程、触点和体验接续方式。
二线管理者为什么沉迷于管理框架：
框架总是简洁而美好的，但实际运行时有许多具体的问题。管理者抱怨员工看问题太浅，没把握本质；员工抱怨管理者不懂情况瞎指挥。实际上持续在一线才可以知道具体情况是什么样，如果已经在二线了，最好相信一线员工一直想用最好的办法解决问题。
为什么企业存在对于敏捷认知退行的现象：
从认知四象限来理解，由于人员更替等因素，新的团队把从前认为是明显的问题退行为需要专家指导的问题，甚至没有人还清楚某一步骤存在的意义，这就成了复杂的问题。随着这类问题越来越多，就出现了敏捷认知的退行。
行业内需要更多的技术官僚：
最初MBA培养的职业经理人不区分行业，可以直接的分辨出企业的问题并作出改进。后来MBA培养区分出行业，需要有行业和技术背景与官僚能力并重。当官僚不够了解技术时，会把专业知识应用到领域对组织的影响进行错误认知和估计。软件行业内不断产生新的技术，旧的技术也在不断的发展，不断对传统产业产生冲击，组织如何吸纳这些新技术，是一直都会遇到的问题。进一步讲，如果官僚无法对吸纳这些技术进行高效的资源调配和编排，就只能在技术边缘，无法内化相关技术形成组织的能力。技术官僚需要懂组织、人力、财务，同时也是技术专家。这样技术官僚可以认识到引入新技术对组织结构、人力成本、财务情况的影响，和需要进行的准备，从而全盘规划，让新技术很快内化，融入到组织当中。
数据的云原生架构-Data Mesh:
目前的企业中比较流行的数据架构，是将数据湖中的数据通过数据流水线产生到所需要的数据制品中。Data Mesh借用了微服务思想，将流水线中的节点改造为一个云原生支持的向外提供数据api、内部包含存储和计算能力的一系列节点。它比起传统的流水线模式，在功能上是等效的，但实现上拥有微服务和云原生的优势。
工程师文化：
1.企业文化四象限： competency （胜任力）、command-controll（命令与控制）、cooperation （协同协作）、cultivation（培养）。其中前两个是非人性文化，关注商业成功；后两个是人性的文化，关注员工工作体验和个人提升。中间两个注重管理和控制，分别导向上下级命令管理或者协同自治的处理工作。如果你的企业寻求自组织，更多的要培养协同文化。
2.工程师文化偏重于两边的两个象限。工程师文化更关注的是技能和技艺，以及如何获得它们。通过胜任力的引入，对员工的能力分级别，对员工的制品区分和量化好和不好，可以引导员工磨炼和提高技艺。工程师文化一定是包含传承的，对个人来说要关注学习的路径和知识的构成，是一种养成型文化；从企业的角度说，雇佣了一个胜任某工作的人，没有传承，技能就没有内化到企业中，随着这个人离职，技能就失去了。所以企业需要厘定线路，思考怎样去要求员工在几年之内达到怎样的层次的胜任力。
职场PUA与形成健康的企业文化：
在职场中，存在一种“领导艺术”，通过让员工失去自信，来达到领导掌握和控制员工的目的，这种现象就是职场PUA。实际上，仅仅是一类的企业文化会产生和鼓励普遍的PUA现象。
企业文化的来源是公司通过绩效奖励鼓励的事情，以及公司面对事情的时候如何做决策。competency指的是画一条合格线，员工要么达到它，要么就走。企业不管理员工，只关注规则的制定、把握和实施。command-controll是要求员工服从上级领导的要求，下级对上级的反馈只包括执行结果，对命令本身没有讨论的余地。大部分公司的金字塔管理结构和职称评级都是这两种文化的体现。cultivation是培养，帮助员工提升能力，而没有直接的目的。cooperation是重视集体主义，员工会将集体内化为身份认同。
前两种企业文化最易产生PUA，命令控制需要使用所有办法强化上级对员工的控制，打压自信只是其中一个管理手段。胜任力仅仅提供一个合格线，而不告知提升能力的路径，是另一种打压手段，最终目的是让员工对其所处的组织结构的位置的认可。而协同与命令结合，通过协同提供一个对事不管人的工作方式，通过命令指定要达到的目的；胜任力与培养结合，通过培养让员工有机会胜任，是更人性和健康的企业文化。
微服务抽取出的业务能力要映射回用户体验：
用户使用产品的一系列体验被称为page flow，后台规划微服务的时候一般把page flow的流程抽象出来，并分析出微服务提供的一个个的能力，通过对业务能力的划分分解，最终把用户体验和业务能力解耦。后期在用户体验变化的时候，只需分析出所需的能力，并对应到微服务的业务能力。
但是一般企业都少了一个步骤，就是把微服务的能力回溯到功能点和用户体验中。这样做会发现可能的情况：有些用户体验类服务与后台服务不强相关，但当前实现的方式较为费劲，而这部分体验不是后端的核心服务内容。最终处理可能是在BFF中，或者高层应用中处理。而如果没有回溯，就不能发现这个问题，因为没有考虑和设计，这个点最终落到核心能力，这样核心能力就不够纯粹和稳定（用户体验容易变，它一变核心就变），系统从微服务化沦为仅仅前后端分离的层次功能。
*来自对八叉说栏目内容的笔记