DDD 一些重要的前提

本周开始正式和大家一起学习DDD，约定说从第五章的实质性内容开始，感觉前面几章的内容相对比较虚。不过S同学提出了不同意见，认为DDD的精髓就在前几章中。仔细想想，也非常有道理，所以先学习一下。

一，统一语言

这是一个看上去很简单，但是实际上却并不那么简单的事，比如我们现在系统中把一个运输的需求称为订单，将一次运输任务称为运单。抱歉这里虽然本意是想解释订单和运单，但是却又引入了需求和任务的概念。凑合着理解吧，看着还挺容易的。

但是到了我们客户这边就变了，客户口中的运单对应的其实是订单，我们的订单到了客户这边叫成了派车单。这就很困扰了，作为SaaS服务商，我们不能只服务一家客户，也不可能因为叫法不同就将所有的字段做定制化，想想唯一的出路是标准化，同化客户，以后客户量越来越大，我们的叫法就是标准。

再稍微泛化一点，大师最近一直在思考运输的本质，那么在我们目前的系统中安排车辆信息，就有四个不同地方可以做，哪一个才是需要的，最好能够合并，不应该做四套。这个问题和统一语言也有那么一点相关，派遣车辆，安排车辆，反馈车辆，车辆预约，这四个术语的本质到底是一样的还是不一样的呢。这可能就不仅仅是一个统一术语的事了，而是要挖掘术语背后的业务含义，这也是DDD的核心精髓之一吧。

二，大声的建模

这个我们看上去有点做得过于好了，每两周的需求范围讨论，总是能爆发几场或大或小的冲突，不过感觉上：

争吵说明在乎，而且大多数时间确实有利于找到业务的本质。所以有些冲突比平淡如水要好。

还是要注意立场，蛋哥今天提到说大家很多时候会带黑帽，以批判的眼光来看问题，我认为批判的眼光问题还不大，更多的时候还是要站在更中立的角度上看问题，避免双重标准。

还是要注意一些沟通技巧，更注意倾听，更有技巧的表达，合理的退让或者妥协会让我们这个专家团队拥有更大的能力

好吧，从我做起。

3，文档化

这是我们今年上半年主要在做的一件事，但是感觉上还有很大的差距，产品，开发要敏捷，高效，但是建模可能也学会慢一点，很多时候做正确的事，把事做正确。然后记录下其中的关键点，可能是现阶段需要关注的事。

DDD 一些重要的前提