如何理解领域驱动设计

极客时间《如何落地业务建模》学习笔记 04

03｜我们要怎么理解领域驱动设计？

从使用统一语言讨论需求，发现模型中的缺失，精炼修改模型，引发统一语言的改变，实现提炼知识的循环。

感觉似乎任何事情只要能够迭代优化，那么都有“极限”的意思，重构、测试驱动开发、持续继承……，味道不错。

不过，在迭代之前，可能需要现有一个安全网或者是指标体系，比如单元测试或者坏味道。

拓展一下，其实如果自己也能够不断的迭代，那么……升职加薪指日可待。有一个问题，就是对于个人发展而言，似乎没有一个指标体系或者安全网。

学生时代的考试成绩可能可以作为度量衡；而工作之后，自然就是用薪资水平来衡量；退休以后最终要的指标可能是身体健康。

看了“用户可以订阅感兴趣的专栏”的例子之后，又回过头去看了上一节中的讲解，有点好奇，这个简单的例子最终会发展到什么程度。

不过如果每个业务程序都可以这样分析的话，想来技术实现的过程会便捷一些。

软件开发的核心难度在于处理隐藏在业务知识中的复杂度

这句话最早似乎源自于《人月神话》，不过谁说的并不重要，但是的确是一针见血。

我觉得本篇最有价值的部分在于对“领域驱动设计”的拆解，一种建模法，一种协同工作方式和一种价值观，我觉的最优价值的部分在于工作方式。但是从实践的难度来说，可能还是价值观最难，知难行易。

对采用领域驱动设计、测试驱动开发、重构的敏捷团队，心向往之。

对于思考题，在关联模型与软件实现的环节上，如果没有单元测试和重构的支持，那么软件与模型的关联就很有可能是瘸腿的，因为既有代码很难修改。

如果是我，如果研发能够支持，那么可能需要从构建单元测试开始，然后逐步引导团队的价值观，最后可能才会有知识消化。

看完这一篇，突然有点迫不及待想去看 DDD。

今天收到了极客时间的礼物，其实之前也收到过，不过最近两个月都没能坚持完成“二十一日挑战”，这个月还有机会。