02｜迭代一概述：怎样开启一个麻雀虽小五脏俱全的项目？
这次迭代的需求
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
领域驱动设计（DDD）是一种以领域模型为核心的开发方法，本文通过介绍迭代一的需求和基本开发过程，展示了DDD实践的基本套路。文章首先介绍了SaaS应用的特点和迭代一的需求，包括租户管理、人员与组织管理、项目管理、人员分配和工时登记等功能。强调了领域专家在需求挖掘中的重要性，并指出部分需求将在后续开发中逐步揭示。整个开发流程包括捕获行为需求、领域建模、架构设计、数据库设计和代码实现等步骤，形成了一个基于DDD的开发闭环。读者可以通过本文了解到DDD实践中的迭代开发过程，以及在实际项目中需求挖掘和实现的参考。文章内容丰富，逻辑清晰，对于想要了解DDD开发方法的读者具有很好的参考价值。
《手把手教你落地 DDD》，新⼈⾸单¥59
全部留言(31)
- 最新
- 精选
aoe置顶第二次学习总结： 1. 从全局视角找出「大功能模块」 2. 在「大功能模块」中找出「子功能」 3.「子功能」推荐以一级列表平铺呈现，可以降低复杂度（反例见需求二），更利于分析问题 详见文章末尾「图例说明」https://wyyl1.com/post/23/06/2023-07-10归属地：浙江1
麋鹿麋鹿迷了路²º²º置顶关于思考题： 1. 如果这是一个真实的项目，你觉得还缺少哪些需求？ 回答：至少还缺少数据报表等分析、项目管理中的审批管理、流程监控等。 此外，我还有一个疑问：DDD中的领域模型，与MVC中的M、ORM中的M相比，三者有哪些异同？作者回复: 关于模型的问题非常好，很多同学可能都有类似的疑惑。首先，是层面不同。DDD的领域模型，属于我们说的“（领域）模型的建立”层面，如果对标传统软件工程的话，大体属于“分析模型”，里面的概念都是业务概念，没有技术概念。而MVC和ORM都是架构模式，属于“模型的实现”层面，按传统的说法就是设计层面，这里面就有业务人员不需要理解的技术术语甚至代码了。ORM里的M，其实就是（分析层面）领域模型转化成代码后的形态，处在代码的领域层。MVC的解释会复杂一点，因为传统的MVC始自SmallTalk语言，而现在一般说的MVC是为了Web应用而改过的。对于Web应用而言，粗略地说，领域层和应用层，都可以归为MVC里的M，而其中的领域层代码，就是ORM里的M。这里我用的“领域层”和“应用层”两个术语，会在我们的课程后面讲分层架构的时候详细介绍。
2022-12-10归属地：广东9
业余草置顶大家的关注点都在需求，我来总结一下本文的核心知识点。 DDD 是以领域模型为核心的。所以，我们可以把上面说的步骤分成“模型的建立”和“模型的实现”两部分。 模型的建立：事件风暴 -> 领域建模。 模型的实现：架构设计 -> 数据库设计 -> 代码实现。 DDD 的基本开发过程：事件风暴 -> 领域建模 -> 架构设计 -> 数据库设计 -> 代码实现。 后面所有的需求，我相信应该都是围绕整个开发过程来讲述的。 期待后面大家轮流来总结，收获满满！作者回复: 您的总结很漂亮。提前说一下，等学到后面的课程会发现，事件风暴只是获取行为需求的方法之一，还可以采用别的方法。所以可以把第一步改一下：获取行为需求 -> 领域建模 -> 架构设计 -> 数据库设计 -> 代码实现，这样可能更好些。不过这仍然是为了讲课简化了的流程，有时间我们可以再更全面的讨论一下DDD和开发过程的关系。
2022-12-08归属地：广东9
程序员吾真本钟老师前面把ddd对于复杂系统的分析的价值和开发人员的痛点讲得很透彻，很赞。另外，在“咱们的系统就是要对这些租户进行增删改查等管理”里的“增删改查”的提法，会不会让一部分听众认为crud不算复杂，为何要用ddd? 另外，并不是所有业务场景把crud都用上。比如只有管理员才可以做对租户进行remove，但租户不可以。是否把“增删改查”改为“根据业务需要对租户信息进行管理”好一些？作者回复: 谢谢道长的建议！这个问题我在写这节课的时候也考虑过，所以您可以看到，目前有些地方用的是“管理”，有些地方用的是“增删改查”。之所以这么写，是考虑两点，第一从课程设计角度出发，第二从实际情况出发。 首先，从课程设计角度，这门课故意模拟实际情况，在真实情况下，业务说需求时可能就是比较随意，这里缺一点，那里漏一点，这里又不一致一点。所以这节课中的需求就显得没那么完善，在后面的课程会逐渐丰满和严格化。 其次，从实际情况角度，当业务说“增删改查”的时候，一定意味着简单需求吗？可能客户目前只想到增删改查，但深挖下去，其实还有别的，可能有的增删改查背后，有复杂的业务校验逻辑等等。这些都要继续挖掘。这节课只是开始，后面的课会继续深挖。总之，还是希望模拟一种真实的开发过程。 至于这种写法是不是有效，我们还可以听听其他朋友的意见。
2022-12-08归属地：广东47
hopez1、个人觉得还缺少数据统计需求； 2、多租户的数据隔离和权限管理不知道属于业务需求还是技术需求；作者回复: 没错。 区分业务需求和技术需求，可以这么想，如果没有开发背景的业务人员能明白的就是业务需求，否则就是技术需求。数据隔离和权限，整体而言，业务人员应该能明白，而且开发人员必须和业务达成一致，所以算业务需求。而数据隔离具体采用哪种技术手段，则不是业务需求，是技术决策。
2022-12-08归属地：广东4
Jaising请教下钟老师，对于需求本身的讨论是不是也要纳入到DDD最小闭环之中，一是不一定能保证业务对需求的把握是准确自洽适合，除了领域专家也需要研发一起参与，二是需求直接影响后面模型建立与实现，哪怕多一条业务规则可能都会影响到建模，更有甚者需求本身就没有充分调研可行导致产研做了无用功，这里就有问题怎么把握需求的真伪、质量、价值这些，DDD有没提供这方面的方法论？作者回复: 准确的说，需求应该包含在软件开发流程的最小闭环中。而DDD的重点其实只覆盖了整个软件开发流程的一部分，也就是从系统分析（不是需求分析）到代码的部分。需求管理本身就可以写一本书了。本课程里的事件风暴，是需求管理的一部分。
2022-12-30归属地：广东23
Jxin
1.有点顺便给自家公司搞个项目管理（包含工时，人员）系统的味道。 2.可以增加的功能 项目工作台，项目仪表盘，项目自动关联，工时缺省填报，工时未填告警等等一系列功能，能做的太多，不罗列了。 3.需要考虑的功能 跨租户业务。 比如商机分销，比如顾问跨租户支援。 这些需要刻画租户模型 租户间协作合同 以及发生跨租户业务后双边的履约刻画以及之间的履约映射 财务结算。 5.少了一个很重要的过程，如何做需求确认。 在未知领域采集业务知识（发散），提炼业务模型/功能点（收敛），评估功能点的必要性（依赖关系）和性价比（按量化价值和成本打分）（发散），制定mvp和演进路线（收敛）。 虽然ddd没写，但这个过程得做，必然可能在开始就凉了。 演进规划一定会有变化，无论是方向还是功能集，可以逐步调整，但不能没有。作者回复: 感谢补充，确实还有一个从愿景，到产品设计，到需求获取，项目规划等的过程。这些足以独立写一本书了
2022-12-10归属地：广东32- 沐瑞Lynn一、从功能需求和非功能需求的角度讲，目前，还没有描述非功能需求； 二、从用户+场景+行为动机+目标来拆解需求，目前，有些场景也欠缺，譬如：如何分配管理权限等
作者回复: 是的，说的很全面。
2022-12-08归属地：广东2 - aoe现在工作中都使用 MVC，代码结构类似 Controller、Service、DAO。 开发时没有体会过“模型的实现”-架构设计这一步，而是：直接根据需求设计数据库 -> 代码实现。 以我现在的水平，看到文末的需求列表就可以直接实现功能了： 1. 划分功能模块：多租户、人员与组织管理、项目管理、人员分配、工时登记 2. 根据功能描述设计数据库 3. 编码实现 感觉到的问题： 1. 这是一门 DDD 的课程，我这样的写出的代码会无比僵硬，没有《DDD》书中提到的有些地方是柔软的 2. 因为代码僵硬，就算使用 TDD 进行开发，有利于后期重构，但也会因代码简陋（没有设计）给重构工作带来很大的工作量 3. 请教钟老师，推荐哪种方法实践： A. 是先按自己的想法实现需求汇总里列出的所有需求，再跟着后续课程迭代功能（我能吃苦，但希望不要走弯路） B. 选一个功能点实现，但是担心选中的这个功能点后续文章直接省略了，重点讲别的功能点（这就有点尴尬了） C. 或者您有更好的建议
作者回复: 每个人都有不同的学习习惯，我只能说一下个人的看法供您参考。建议您先忘记代码，跟着课程尽量先吃透领域建模。到了后面的代码实现部分，我其实只写了一个功能为例，你看了以后，可以用类似的方法尝试写其他功能。然后和自己头脑中原来的做法做比较，应该就可以了。
2022-12-08归属地：广东42 
6点无痛早起学习的和尚在这里发现一个细节问题，在捕获行为需求阶段，我们梳理了： 1. 需要提供的功能（这里就为后期提供接口功能做铺垫，也算是为功能架构设计做铺垫） 2. 功能下面一些数据之间的关系（这里就为后期做数据库设计做铺垫），比如一个合同下面可以多个项目，这里就是 1：N 的关系 不知道这样理解是否正确作者回复: 基本是正确的，我再补充一下： 1.关于捕获行为需求，这一课只是开了一个头，下两节课讲事件风暴才是主要部分，在那里，会对后期接口设计起到更具体的作用。 2.按照DDD，这里的需求和数据库设计之间还差了很重要的一步，就是领域建模，领域建模以后，才数据库设计。这是DDD和之前开发方法的主要不同之一。
2022-12-09归属地：广东1
