1.微服务拆分过细
DDD的兴起的确是在微服务的流行后,才真正得到开发人员的重视。DDD的可以帮助我们更加合理的进行微服务边界划分。所以很多人的对他的认知都是DDD只适应于微服务。这个认知并不能算是合理的。单体架构也可以适用DDD的设计方法论。互联中我们有碰到很多微服务拆分过渡导致项目维护、管理难度加大,甚至失败的都有。我们一个团队可能就10个人,当我们面对一个小商城系统时,我们可能会噼里啪啦一下拆了20多个微服务出来,这个是很恐怖的。因为一旦微服务化很多问题都会接踵而来,事务、超时、熔断、限流、服务监控、排错等问题。我们有限人员可能一下都耗费在这与业务无关的上面去了,这个是很严重的问题,过渡服务化。我觉得根据人员配置情况进行模块划分会是一个很合理的方案。首先我们粗粒度的形式进行划分。各领域之间还是遵循DDD的设计方法论,该怎么拆分模块就怎么拆,虽然他们可能都在一个大的模块里,但是这个不影响。当那天我们项目成功了,用户上来了,我们再把这些模块拆分出去也是简单的。因为我们已经划分好限界上下文,划分好领域,代码之间也不存在耦合和强引用关系。
不知道大家有没发现这里面其实还隐藏了一个问题就是人员的问题。服务我们虽然划分好了,人员那到底应该怎么去配比呢?
例如:我们按照业务来划分,根据粒度大小,一般会存在以下两个情况。
1.分为商品、交易、用户3个服务;
2.分为商品、订单、支付、物流、买家、卖家6个服务。
但是我们只有10个人的情况下,我们该如何选择以上两种方案。
我们可以依据“三个火枪手”原则。三个人分配一个服务的原则进行人员配比。
具体什么是"三个火枪手原则"看下图
2.系统所有领域都使用DDD进行设计
有一部分人在完成DDD的学习后,当有新的业务需要开发的时候,把所有的模块都按照DDD的方式来进行设计。我觉得这个是不可取的,觉得DDD是把锤子,就把所有的问题都当做钉子来处理。我觉得我们应该要聚焦我们的业务核心,划分清楚哪些是核心域、通用域、支撑域,我们应该要着重在核心域和支持域上,当我们人力不足时支撑域、通用域都可以采用传统的开发方式也是可以的,毕竟收悉的人比较多实施成本较低,DDD对团队的设计和技术要求度都比较高,在没有足够的能力支持下,所带来的问题可能会比传统的开发方式的问题更多。