开始领域驱动设计 - 思维的转变

引用一段别人说的话: CRUD是业内的大失败。我们欺骗自己,认为我们的应用无非是在数据库上薄薄的一层。我们给用户的grids和add/edit表单,并要求他们填写的字段,然后或多或少直接映射到数据库的关系表。我们称之为“数据模型”。

CRUD操作简单易学,一个初级开发人员可以很快的上手,在很长时间内你都可以一直重复CRUD来开发不同的系统并且只包含很少的变化,它就像一个食谱。

然而真正的处理和业务不只是CRUD。真实的人类不会说:“我已经设置了支付金额的订单为“120”,支付货币的“欧元”,和把状态设为“已支付”。他们说,“我用120欧元支付订单”。

这时候你必须使用领域驱动来思考你的需求/用例,这可能是一个艰难的转变过程。一个好的领域模型不是一个数据模型。领域模型描述行为,数据只是一个产物。领域模型使我们的用户需求/用例转变成代码。

在开始一个项目之前,你需要问问自己这是否真的只是一个简单的CRUD应用,如果它拥有业务概念和领域、或者有一定的业务流程,那么忘记CRUD。

不适用DDD的场景:

如果你想从用户那里获得一些数据,做简单的处理,将其保存到数据库,然后重新呈现给用户,这就是一个CRUD应用程序。你真的不需要花哨的东西,你只需要创建所需的数据结构,一个简单的ORM是非常有用的,比如mybatis,简化了重复枯燥的任务。

适合DDD的场景:

这是一个将很可能随时间演化的复杂系统,需要建立更精确的模型行为,将现实世界中的业务抽象成代码。并不是持久化了什么数据,而更关注整个业务流程。不要把CRUD当成一种业务,CRUD只是仓储的行为,真正业务是一种和时间有关的活动,需要你从需求/用例中挖掘。

相关文章

什么是设计模式一套被反复使用、多数人知晓的、经过分类编目...
单一职责原则定义(Single Responsibility Principle,SRP)...
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强...
适配器模式将一个类的接口转换成客户期望的另一个接口,使得...
策略模式定义了一系列算法族,并封装在类中,它们之间可以互...
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,...