读书笔记

前言

地图就是模型，而模型被用来描绘人们所关注的现实或想法的某个方面。模型是一种简化。它是对现实的解释一把与解决问题密切相关的方面抽象出来，而忽略无关的细节

💡故事

1)模型和设计的核心互相影响

💡减少沟通成本

2)模型是团队所有成员使用的通用语言的中枢。

第1章消化知识

💡线性知识传递，当层级较多时出现信息将被r消耗，这要求团队扁平化，另外如果团队就个人就没有消耗了 (AI?)

在传统的瀑布方法中，业务专家与分析员进行讨论，分析员消化理解这些知识后，对其进行抽象并将结果传递给程序员，再由程序员编写软件代码。由于这种方法完全没有反馈，因此总是失败。分析员全权负责创建模型，但他们创建的模型只是基于业务专家的意见。他们既没有向程序员学习的机会，也得不到早期软件版本的经验。知识只是朝一个方向流动，而且不会累积。

💡被外包出去的关键子系统可能只交回了代码，而不会将知识传递回来。

已经学到了一些知识的人可能干别的事去了。团队可能由于重组而被拆散，这导致知识又重新分散开。被外包出去的关键子系统可能只交回了代码，而不会将知识传递回来。而且当使用典型的设计方法时，代码和文档不会以一种有用的形式表示出这些来之不易的知识，因此一旦由于某种原因人们没有口头传递知识，那么知识就丢失了。

第2章交流与语言的使用

💡成本计算在内

将模型作为语言的支柱。确保团队在内部的所有交流中以及代码中坚持使用这种语言。在画图、写东西，特别是讲话时也要使用这种语言。 通过尝试不同的表示方法（它们反映了备选模型）来消除难点。然后重构代码，重新命名类、方法和模块，以便与新模型保持一致。解决交谈中的术语混淆问题，就像我们对普通词汇形成一致的理解一样。

有了UBIQUITOUS LANGUAGE之后，开发人员之间的对话、领域专家之间的讨论以及代码本身所表达的内容都基于同一种语言，都来自于一个共享的领域模型。

💡所以会有债

由于为代码添加的注释并不影响程序的行为，因此它们往往无法与当前代码及其模型保持同步。外部文档和图也不会影响程序的行为，因此它们也无法保持同步。

💡避免文档脱节，所以少写文档...

限编程主张完全不使用(多余的) 设计文档而让代码解释自己。实际运行的代码不会说谎，而其他文档则不然。运行代码所产生的行为是明确的。

思考--与ClaudeAI的讨论

我：DDD领域建模强迫客户或使用者也理解软件思维，这不是一种浪费么？ Claude：这是一个有趣的观点。DDD领域建模的确要求业务领域专家和开发团队达成共同的领域理解,这在一定程度上要求业务人员采用软件工程的思维去理解和表达业务概念与流程。这的确在一定程度上增加了业务人员的学习和理解成本。但是,DDD领域建模带来的好处远超这一点成本:1. 达成共同语言。软件开发往往面临"Impedance Mismatch"的问题,领域建模可以帮助业务和技术团队达成共同的语言和理解,减少误解与偏差。2. 更清晰、准确的业务理解。软件工程的思维方式可以帮助业务人员在微观层面上更清晰和准确地认识业务,发现隐藏的细节与边界。这有助于打造出更加贴近真实业务的软件。3. 可持续的软件设计。基于领域驱动的软件设计可以让业务概念和软件模块达成高度契合,使软件系统具有更好的可扩展性、灵活性和可维护性。这使得软件具有更长的生命期。4. 减少重复工作。相比ordinary software development, DDD可以最大限度重用分析和设计,减少重复劳动,提高开发效率。综上,虽然DDD领域建模在一定程度要求业务人员理解软件思维,但由此带来的好处远超这一点成本。达成共同语言、提高业务理解、设计可持续软件、减少重复工作,这些都是DDD领域建模的重大好处,可以显著提高软件的质量和开发效率。所以,我不认为要求业务人员理解软件思维是一种浪费。恰恰相反,这是实现高质软件开发的必经之路。业务人员付出一定理解成本,可以获得软件开发全生命周期的收益,这是值得的。软件开发离不开业务,业务理解也需要技术支持,DDD领域建模正是连接二者的桥梁。总之,合理运用DDD领域建模,让业务和技术达成共识与理解,这并非一种浪费,而是高效和高质软件开发的基石。业务和技术需要相互理解,这是一种双赢的合作,也是软件工程发展的必然。

我：客户除了支付软件开发的费用成本，还应该承担沟通成本，学习软件思维成本，学习使用软件的成本，再项目初期客户就应该考虑这些，或由合同说明 Claude：你说的很对。对客户来说,软件开发项目不仅包含开发费用,还包括:1. 沟通成本:与开发团队进行需求分析、过程沟通等需要耗费时间与精力。2. 学习成本:理解软件思维方式与表达,熟悉软件系统,这需要一定的学习成本。3. 使用成本:软件上线后,用户使用与运维也需要成本投入。这三项成本加起来,往往会超过开发费用本身,这也是客户在选择软件开发服务时需要考量的因素。

我：往往客户只想花钱解决问题，而不是学习 Claude：你说的对,许多客户的心态是"花钱解决问题"。他们只注重软件系统可以达成的业务目标,而忽略整体的项目成本与投入产出比。这也导致许多软件项目超支或无法达成预期目标。所以,作为客户,选择软件开发服务前需要全面考量:1. 开发公司的技术与服务能力:不仅要达成需求,还要控制成本和支持后续服务。2. 自身团队的软件理解与沟通能力:理解软件思维方式,熟练表达需求,才能高效沟通。3. 项目整体成本投入产出比:不要只看开发费用,要考虑项目全生命周期的成本收益。4. 后续软件使用与运维投入:选用易于理解和运维的技术与方法。5. 合同约定及责任:明确各方的责任、沟通方式和相关成本承担,避免费用超支和无法达成目标。综上,客户选择软件开发服务时,不能只着眼于解决问题和开发费用。更重要的是考虑项目全成本,选取技术成熟的开发伙伴,建立高效的沟通机制,并在合同中做好成本约定。只有在项目全生命周期内达成预期目标并控制成本,软件开发项目才算成功。总之,你的观点很精确。客户除了开发费用,还需要考虑各种软件项目相关成本。这需要客户与开发伙伴建立共识并在合同中做好约定,这是实现软件项目成功的基石

我：DDD在领域建模时如何保证软件需求范围，在建模时很可能因为客户参与，或开发参与导致需求颗粒度变大而需求蔓延 Claude：在领域建模时,为了保证软件需求的范围,可以采取以下措施:1. 明确需求范围边界。在项目开始时,应与客户达成一致,明确需求范围的边界,决定哪些需求属于此次建模和开发的范围,哪些需求暂时排除在外。这可以避免需求蔓延。2. 细化需求,控制颗粒度。可以与客户和开发人员一起讨论,将高层次的需求进一步细化和具体化,控制到适当的颗粒度,不至于太抽象或太具体。这有助于建模人员理解需求,也方便后续开发。3. 区分必要需求和可选需求。可以将需求区分为必要需求和可选需求,必要需求是此次开发必须实现的,可选需求可以在此次开发中实现,也可以在后续版本中实现,这有助于控制需求范围。4. 迭代建模和验证。采用迭代的建模方法,不断与客户和开发人员核对需求理解和建模结果,验证模型是否准确地表达了需求,修正建模错误或更新需求。这种迭代验证可以确保建模始终围绕需求范围开展。5. 约束建模工具和技术。选择适当的建模工具和技术,可以在一定程度上约束和控制建模人员,避免建模过于抽象或具体,超出需求范围。比如选择适度的建模粒度和模型表达能力较强的工具。以上方法可以有效地保证软件需求范围,控制需求的蔓延,帮助建模人员专注于需求范围内的建模工作。但需求范围的控制也依赖于客户和开发人员,需要沟通达成一致,才能真正发挥作用。