一、管理面问题：传统scrum敏捷流程中的问题

设计和编码断层

在传统的迭代流程存在设计和编码断层，大致如下：

图片 在软件开发的实践中，我们经常面临设计和编码之间的断层问题。一些团队在开发过程中，可能会因为时间压力或对需求的自信，而简化或忽略设计阶段，直接进入编码。这种做法虽然能够快速启动项目，但往往会导致后期出现需求理解不足、设计不充分等问题，进而影响软件的质量和可维护性。

敏捷开发模式下，迭代速度快，开发团队可能会更注重功能的快速实现，而忽视了设计的重要性。开发经理可能认为，只要功能能够快速上线，其他问题可以后续解决。但这种急功近利的态度，可能会导致项目在后期面临更多的技术债务和维护难题。

此外，业务和开发之间的隔离也是一个常见问题。业务团队在完成需求文档后，可能会转向其他项目，而开发团队则专注于编码实现。如果双方在需求理解上存在偏差，而没有及时沟通和确认，最终可能导致产品与预期不符，引发不必要的冲突和返工。

为了解决这些问题，领域驱动设计（DDD）提供了一种有效的解决方案。DDD强调业务与技术的紧密结合，通过统一语言和领域模型，强化设计和编码之间的依赖关系，从而减少业务与开发之间的断层。通过实施DDD，团队可以更好地理解和实现业务需求，提高软件的质量和可维护性。 图片 在软件开发过程中，业务与开发团队之间的沟通障碍常常导致需求理解的偏差。为了解决这一问题，引入领域专家并采用通用语言进行领域驱动建模显得尤为重要。通用语言是一种所有团队成员都能理解的统一语言，它有助于消除歧义，确保团队成员在讨论同一概念时使用相同的术语。 通用语言的构建基于团队成员间的深入讨论，通过事件风暴等活动，形成共识。它不仅包括了业务术语，还涵盖了用例场景，使得语言能够直接反映在代码实现中。例如，在电商系统中，无论是程序员、产品经理还是测试人员，都使用统一的术语来描述用户购买商品的行为，如“用户下单”或“商品购买”。 通用语言的运用，使得领域对象如商品、订单等名词可以直接用于代码中的实体命名，而动词如下单、付款则对应领域事件或命令。这种语言的一致性贯穿整个领域驱动设计（DDD）过程，帮助团队成员将业务需求准确转化为代码设计，从而提高代码的可读性和可维护性。 领域驱动设计的核心在于将业务领域作为解决问题的出发点。面对业务需求时，首先提炼出关键的领域概念，并构建领域模型来表达这些业务问题。在这一过程中，应避免过早地涉及技术实现的细节。编码实现则被视为对领域模型的直接翻译，要求代码中的元素如变量名、方法名、类名等都能够清晰地表达领域概念，实现见名知义的效果。 通过这种方式，DDD不仅促进了业务与技术的融合，还提高了软件项目的开发效率和质量。 图片 在采用领域驱动设计（DDD）之前，我们通常采用的是数据库驱动设计。这种设计方法以业务需求为出发点，通过数据建模来创建类，并利用对象关系映射（ORM）技术将这些类映射成数据库表结构。然后，为了提高读写效率，我们会使用范式来优化表之间的关系。这种以数据为中心的设计思路，虽然能够直接反映业务需求，但却缺乏对领域知识和规则的深入理解。当业务需求发生变化时，数据模型和数据库设计往往需要随之调整，这导致系统对变化的响应能力较弱。

在协同工作方式上，数据驱动设计模式下，产品团队提出需求，研发团队负责设计和实现。这种工作模式的缺陷在于，缺乏一个能够统一认知差异的模型。产品团队从业务角度出发，可能会提出一些变化多端、定制化的需求。而研发团队在缺乏行业经验的情况下，可能会直接将这些需求转化为数据模型。同时，研发团队在设计技术方案时，会涉及到许多技术细节，产品团队可能难以判断这些技术方案是否与业务需求和产品规划相符，从而导致认知差异。这种差异随着迭代的进行可能会不断扩大，最终导致系统变得难以维护。 图片 DDD（领域驱动设计）通过引入“领域专家”角色和模型驱动的设计理念，有效缩小了产品与研发团队之间在认知上的差异。领域专家凭借深厚的行业经验和丰富的知识储备，能够从变化多端、高度定制化的需求中，提炼出明确的界限，形成稳定且可复用的领域概念和业务规则。他们与产品和研发团队紧密合作，共同构建出精确的领域模型。

设计的核心理念在于区分变化与稳定，确保领域模型的稳定性，从而提高代码的可维护性和生命周期。领域模型是业务需求的抽象表达，不涉及具体的技术实现细节，但为研发团队提供了编码实现的指导。这消除了产品和研发团队在需求理解上的分歧。

模型驱动设计强调领域模型与业务需求和编码实现的紧密联系，领域模型的任何变更都直接关联到需求和代码的变更。团队协作以模型为中心，围绕模型进行需求分析、设计和实现。 图片 精炼循环是一个重要的概念，它涉及到在软件开发过程中，通过持续的迭代和反馈，逐步提炼和完善领域模型。这一过程包括使用统一的语言来定义领域概念，明确模型的边界，构建相应的模型，并将其与具体的实现相绑定。在这一过程中，各个环节相互影响，相互促进，通过不断的试错和调整，最终形成稳定且深入的领域模型。例如，在提炼领域概念时，如果发现统一语言的定义存在问题或歧义，就需要重新调整定义，并再次进行概念提炼。 精炼循环的目的是形成稳定的领域模型，其核心在于分离出稳定和不稳定的部分。通过这种方式，可以保证领域模型的稳定性，从而提高代码的可维护性和生命周期。在领域驱动设计（DDD）中，领域专家在概念提炼和边界划分等宏观设计方面发挥着重要作用，这是因为他们的经验和行业洞察是基于过去无数次精炼循环的积累。因此，由领域专家主导的宏观设计往往能够产生非常稳定的领域模型。 精炼循环的关键在于循环本身，它避免了知识单向流动，防止了因各环节上的认知差异而导致模型无法在产品、领域专家和研发之间达成一致，从而避免了模型与实现的割裂。