领域模型驱动开发(1)

摘要

习惯了MVC模式，习惯了敏捷开发，习惯了了小步快跑，还适合谈论领域驱动开发吗。领域开发是否就是慢节奏的开发，
本文结合自己的开发经历，和大家聊聊这个话题。

#一.业务代码是如何写烂的#
java web开发通常都是mvc模式，从早期的ssh逐渐到Spring+ Mybatis。所以通常一个工程的项目结构图就是

• controller
• service
• manager
• dao

问题1： bean的职责不清

对应的bean就是
PO/DO（Persistence Object/Data Object）：与数据库表结构一一对应，通过 DAO 层向上传输数据源对象
DTO（Data Transfer Object）:数据传输对象，Service 和 Manager 向外传输的对象。
BO（Business Object）： 业务对象。可以由 Service 层输出的封装业务逻辑的对象。一般不需要，
Query：数据查询对象，各层接收上层的查询请求。
VO（View Object）： contoller层对外提供的

一般至少有PO/DTO/VO 三层结构，但是对于有些项目结构，业务比较简单，就是CRUD,有些开发人员就只有两层，controller到dao层就完了，然后bean的定义也特别混乱，随意创建，导致bean漫天飞，通常除了自己明白其中的含义，其他人都不明白，复用性极差。

问题2：面向过程的设计
此外 bean中都是属性，除了equals方法就都没有了。虽然有接口和实现，但是按照这样一套写出来的代码基本上和面向过程写的代码没有什么区别。这种开发方式bean类只有属性，没有行为。这样就会导致某一个实体的变更会散落在各个service中，而不是这个领域实体中。

问题3：不考虑业务模型
现在都是敏捷开发，导致开发人员也变得浮躁了，不分析或者草率分析需求，拿到就是干，随着业务迭代，开发人员增加，每个人各写一套，关于一个名词的定义都能有好几套写法，sql查询可能会分散到好多repo中，相同的sql可能会在不同的地方写上好几遍。关键是发现之前的模型定义错了，数据库的ER图设计有问题，仍然不会去更改，因为总是有新的需求会来，然后拼了命的做需求，留下一堆烂代码无法维护，最后连自己都不想看。

二. 领域模型是如何发挥作用的

比如说一个平台，一开始只有一种用户身份，后来平台做大了，开始做交易了，区分出了商家了，和买家了。产品提了个需求开发一个商家入驻流程，吭哧吭哧开发完了。一段时间后，开始需要有中间推销商了，一部分买家可以变成中间推销商了，那这时候产品跟你说，不用搞入驻流程，直接赋予原来的买家额外属性，来区分是否可以推销商品。这时候你能同意吗？

当然不行了，因为这个业务需求本质是就是交易，有买家，有卖家，有中间商。他们属于交易维度的不同实体，是同一个层次的，而用户则是不同的层次。一开始产品只会有需求说判断是中间商就可以，没有其他的了。等你在用户实体上加了一堆属性后，过了一段时间后，产品就会来跟你说，不好意思，哥们，卖家想管理中间商，需要中间商提供一些资质，你再帮我加几个属性。然后你的用户实体的模型开始无限扩张的模式了。对于产品来说，他是无所谓的，快速上线验证，验证了不行，换另外一条路，但是作为开发就被坑的天天加班了。

所以领域模型可以帮你解决，通常一些对于一些通用的领域，你可能很好找到对应模型设计，比如说订单，商品，抽奖，优惠券。但是这也需要你去阅读相关的产品文档，领域设计，当然如果你有一个靠谱的产品，你可能会轻松很多。而有一些不是通用领域的，所以需要你与你行业领域专家去深入聊，才能设计的出来领域模型，另外一点就是通常在一开始，会有些领域模型设计的有问题，需要不断的思考，纠正。