瀑布和迭代

 "设计人员做好设计，结果交给编码人员，由编码人员实现"，这看起来很好！
这种方法中存在的一个主要的问题是分析无法预见模型中存在的某些缺陷以及领域中的所有的复杂性。分析人员可能会过多深入到模型中某些组件的细节，但其他的部分却缺乏足够的细节。 非常重要的细节直到设计和实现过程才被发现。 
    瀑布设计方法，业务专家=提出=〉需求=>业务分析人员=创建=〉设计模型==〉开发人员=〉编码。
在这个方法中，知识只有单一的流向。 虽然这种方法作为软件设计的一个传统方法，这么多年来已经取得了某种程度上的 成功应用，但它还是有它的缺点和局限。 主要问题是业务专家得不到分析人员的反馈信息，分 析人员也得不到开发人员的反馈信息。 
    另一种 方法是敏捷方法学，例如极限编程（ XP）。这些方法学是不同于瀑布方法的一些活动 ，其 产生的原因是很难预先确定所有的需求，特别是在 需求经常变化的情况。 要想预先创建一个覆盖领域所有方面的完整模型确实非常困难。 需要做出大量的思考，而且在初期常 常无法看到涉及到的所有的问题，也 无法预见到 设计中某些带有负面影响或错误的部分。 敏捷方法试图解决的另一个问题被称为" 分析瘫痪" ，团队成员会因为害怕做出任何设计决定而止步不前。 尽管敏捷方法的倡导者承认设计决定的重要性，但他们反对做出预先设计。 相反，他们借助于实现层面的灵活性，通过由业务涉众持续参与的迭代开发和很 多重构，开发团队更多地学习到领域知识。
    ---DDD Quikly