如何在工作中使用DDD
或许你只是一个普通的程序员,对项目没有任何的控制力,而且只能使用公司中成熟的框架程序;
或许你是一个项目管理者,但是这个项目太大了,涉及了好多方面,你无法自己决定一切。
总之,当我们很多人在学习了DDD之后,遇到的最大的困惑就是:到底在什么地方使用它呢?
自己做个小东西玩玩?总觉得不是那么回事。
想在项目中使用,可是自己没有决定的权利,公司不会轻易改变已经稳定的东西。
所以,学习 DDD,第一步就是要学会 使用 DDD 的思想去分析需求--脑袋长在自己脖子上,别人管不着吧?
根据需求,去分析出领域模型,模型之间的关系,等等。分析需求没有规范,没有框架吧?
分析完了,到实现了,也就是编码。我觉得这个时候大家不必苛求太多,如果能自己决定架构,那么就决定;决定不了,就沿用。虽然实现上可能会别扭,不过在分析阶段已经透彻的话,那么你就比别人站在了更高的角度看问题。
别人指的是什么人?就是以数据库为主导思想的人。我相信,使用 DDD 后分析的产物,再去创建数据库结构,一定会更清晰。不过如果你的领导喜欢讨论数据库设计,那么也一起讨论,没准能弥补你的分析。
用一个例子来描述一下这个过程。
例如现在有一个需求:系统中有“用户”这样的人,“用户”能够买“道具”。
分析后,我们会得到这么两个领域模型:用户 和 道具。
那么用户所购买的道具呢?应该是 用户 模型中的 一个部分道具的集合。
所以,从领域模型的角度来看,我们只需要创建两个类:用户 和 道具。
至于用户所购买的道具,应该是 用户类中的一个表示道具集合的变量。
可是,如果从数据库的观点出发,除了 用户 和 道具 的表,还应该有一个 用户购买的道具 的表。所以------如果是使用传统的 表-类 映射的这种框架,我们需要创建三个类:用户 , 道具 , 用户购买的道具。
这确实很让人矛盾--------不过不要在意这样的矛盾,记住:你已经分析清楚了系统的模型关系,如何实现,那不是重要的。即使用 php 来实现,也是一样的道理。
所以,先实现第一步,在分析中使用DDD,至于第二步,第三步,就得看环境了。