Sir*_*lot 3 agile domain-driven-design
我们正在尝试在项目中应用领域驱动设计.然而,建模工作量巨大,并且在某种程度上,建模似乎与敏捷原则相冲突,因为许多前期设计已经完成.另一方面,实际利益是分散的或相当长期的,而"需求分析/建模开销"感觉是一个尖锐和持续的问题.
那么,问题就出现了:域驱动设计的价值是什么？有什么短期利益？
除了你的经验(我觉得非常有趣):是否有一个无可争议的合乎逻辑的答案？
Chr*_*mon 14
我想我会澄清一下,领域驱动设计并没有要求进行大量的前期建模 - 它所要求的是与领域专家的对话,通过"明智的声音"使用知识来获得对领域的直观理解.无处不在的语言,以及对上述所有内容的不断完善.
战术模式(聚合等)的价值不在于让模型完美呈现,而是从构建应用程序开始,这样当您不可避免地意识到在模型中有更好的表达域的方式时,您可以迭代并将您的见解融入更新的模型中.
所以 - 在这个意义上,它非常支持敏捷方法.
对此最好的参考是来源 - " 埃里克·埃文斯的蓝皮书 "中的"第三部分重新深入洞察"
我建议不要试图"模仿"你的模型,然后"敏捷"你的代码 - "敏捷"他们两个,并接受你将重构你的代码,而不仅仅是当你找到一种更优雅的方法来解决技术问题时,而且当你找到一种更优雅的商业问题建模方式时.
就"无可争议的合理答案"而言 - 说实话,我不确定你会找到一个.DDD是一种由不同的人以不同方式应用的方法 - 它不是可以分析它的大O复杂性的算法.
我的经验是,通过一系列松散相关的服务分散的具有贫血模型和业务逻辑的程序难以迭代并将更深入的见解纳入业务需求,因为规则的更改可能会在整个系统中产生无法预料的影响.他们鼓励通过将行为填充到从未打算过的地方来满足新要求的系统,并最终进行涉及多层记忆的对话,使用"员工"这个词有时与"学生"的要求有关.和'老师'.
将每个实体的本质集中到一个类中,并将其暴露在意图揭示界面背后的行为,可以有效推理变更的影响,从而实现模型的持续重构 - 包括理解增长和需求变化.
从您的评论中,我现在更好地理解您的意图 - 我误解了您希望说服DDD值得的问题 - 而是您正在寻找一个论据来向您的团队说服它是值得的!
不幸的是,这更像是一个人际问题,而不是一个技术问题,因为一旦他们确信他们走在正确的道路上,人们往往不会被论证所说服.
也许如果你有时间,你可以产生一些验收测试和领域模型的概念证明来说明使用你域中的真实概念的方法？然后,您可以展示随着理解的增长,测试和模型的演变是多么容易,并且理想地展示通过在代码中积极建模域并执行模型而获得的洞察力.我认为,这是关键,因为在我看来,这样的见解只能通过积极的行动来获得,而且永远不会通过会议室肚脐凝视来达到.
| 归档时间： |
|
| 查看次数： |
1189 次 |
| 最近记录： |