DDD实践：构建业务与技术统一语言.pdfVIP

《005_DDD的价值：让业务和技术有相同的理解（2）》

你作为技术，你一定不能自己随便定义代码里的任何一个类名、方法名、参数名、属性名、

变量名、接口名、数据库名，刚开始你不能随便去定义，产品经理找业务方去聊需求，聊完

了以后出需求文档，找你来聊

需求文档一般会产品经理找技术团队来进行需求评审，技术来听产品讲解一下系统和功能，

以及需求，听懂，这里你就会初步的积累这个系统对应的业务知识

业务建模，针对team负责的这个系统去进行通用语言的设计，技术团队应该找到

业务方，比如说产品、用户、运营，大家一起开会讨论，一起设计这个系统（限界上下文）

的通用语言-战略建模

你就直接出技术设计，设计review的事儿，跟产品经理、业务方也好，是没有关系的，粗

略的，业务架构和技术架构，表结构的设计和接口名的设计，接口的业务流程的图，其他的

就没有

直接找技术团队里的leader和其他成员进行技术设计的review，业务模型，架构设计，技

术选型，方案设计

一定会导致具体的工程师在写代码的时候，会自己胡乱的定义类名、方法名、参数名、属性

名、变量名、接口名、数据库名，进而导致，他开发出来的代码可能是屎，但是也能实现需

求里的功能，也能通过测试，也能交付软件

写代码之前，还必须大家都进行细化的领域对象的建