Golang领域模型开篇，当Go遇上DDD

你知道的越多，不知道的就越多，业余的像一棵小草！

你来，我们一起精进！你不来，我和你的竞争对手一起精进！

推荐：https://www.xttblog.com/?p=5070

我本身就是一个不太会拒绝的人，这点和雷军相似。最近一周，有网友说要给我投稿，内容见本文。所以，本文是转载的一篇文章，有喜欢的可以深入学习！

freedom

DDD是什么？

领域驱动设计(DDD) 做为一种软件工程的方法论，它可以帮助我们设计高质量的软件，或者说任何工程的设计都需要方法论，不论是城市设计、建筑设计、室内设计。

比如没有方法论的情况下楼是可以盖起来的，或许整个楼道和窗户上挂满了电话线、闭路线、电线？下水道隔三差五就堵了？某一户跳闸了导致整个楼都停电了？那么盖楼前是否有好的方法论去建模呢？

不论任何行业的工程设计都因该使用正确的方法论去设计。任何行业的方法论也离不开八个字分而治之、拥抱变化。如果和城市的设计、建筑的设计相比较，我认为软件的设计会更复杂，软件的迭代和变化周期更快，也意味着我们更需要好的方法论。

uml

DDD 是一个分而治之的过程，是一系列分而治之的方法论。

如何把一个公司的领域划分成多个子域，比如教育公司会划分成作业子域、课程子域。电商可能会划出商品子域、物流子域。如何为每个子域划分出多个实体、聚合、服务，如何每一个实体和聚合设计它们的事件，如何为每一个实体设计它们的仓库。这就是DDD要做的事情！

贫血和充血？

贫血的代码是指数据和行为的分离，业务系统迭代中行为多变和数据的多变会导致代码的难以维护。来看一个贫血读取商品的演进

package service///获取商品func GetGoods(goodsId int) dao.Goods {  return orm.GetGoods(goodsId)}

PM 一个月后增加了自动选择优惠券功能

//增加了优惠券package service//获取商品func GetGoods(goodsId int) dao.Goods {  return orm.GetGoods(goodsId)}// 获取有优惠券的商品func GetGoodsByCoupon(goodsId int) dao.Goods {  goods := GetGoods(goodsId)  coupon := orm.GetCoupon()  //优惠券和商品逻辑略过....  return}

PM 2个月后加入了限时折扣，不可以叠加优惠券，自动选择最优。

这个限时折扣该加哪，虽然各种if else也能加，那么以后pm在加逻辑呢？这里就不浪费笔墨了。


充血的代码

func GetGoods(goodsId int) entity.Goods {   //获取优惠券实体   coupon := repository.GetCoupon()   //获取商品实体   goods := repository.GetGoods(goodsId)

   //如果优惠券减免大于限时折扣   if coupon.SubPrice(goods) > goods.TimeLimitPrice() {       //使用优惠券       goods.UseCoupon(coupon)       return goods   }   return goods}

//实体不应该仅仅只有数据，而且必须要有行为func (c *coupon) SubPrice(goods entity.Goods) int {}

func (c *goods) TimeLimitPrice() int {}func (c *goods) UseCoupon(coupon entity.Coupon){}

战略和战术？

go