领域驱动设计使用中的误区

1.微服务拆分过细

DDD的兴起的确是在微服务的流行后，才真正得到开发人员的重视。DDD的可以帮助我们更加合理的进行微服务边界划分。所以很多人的对他的认知都是DDD只适应于微服务。这个认知并不能算是合理的。单体架构也可以适用DDD的设计方法论。互联中我们有碰到很多微服务拆分过渡导致项目维护、管理难度加大，甚至失败的都有。我们一个团队可能就10个人，当我们面对一个小商城系统时，我们可能会噼里啪啦一下拆了20多个微服务出来，这个是很恐怖的。因为一旦微服务化很多问题都会接踵而来，事务、超时、熔断、限流、服务监控、排错等问题。我们有限人员可能一下都耗费在这与业务无关的上面去了，这个是很严重的问题，过渡服务化。我觉得根据人员配置情况进行模块划分会是一个很合理的方案。首先我们粗粒度的形式进行划分。各领域之间还是遵循DDD的设计方法论，该怎么拆分模块就怎么拆，虽然他们可能都在一个大的模块里，但是这个不影响。当那天我们项目成功了，用户上来了，我们再把这些模块拆分出去也是简单的。因为我们已经划分好限界上下文，划分好领域，代码之间也不存在耦合和强引用关系。
不知道大家有没发现这里面其实还隐藏了一个问题就是人员的问题。服务我们虽然划分好了，人员那到底应该怎么去配比呢？

例如：我们按照业务来划分，根据粒度大小，一般会存在以下两个情况。
1.分为商品、交易、用户3个服务；
2.分为商品、订单、支付、物流、买家、卖家6个服务。
但是我们只有10个人的情况下，我们该如何选择以上两种方案。
我们可以依据“三个火枪手”原则。三个人分配一个服务的原则进行人员配比。

具体什么是"三个火枪手原则"看下图

2.系统所有领域都使用DDD进行设计

有一部分人在完成DDD的学习后，当有新的业务需要开发的时候，把所有的模块都按照DDD的方式来进行设计。我觉得这个是不可取的，觉得DDD是把锤子，就把所有的问题都当做钉子来处理。我觉得我们应该要聚焦我们的业务核心，划分清楚哪些是核心域、通用域、支撑域，我们应该要着重在核心域和支持域上，当我们人力不足时支撑域、通用域都可以采用传统的开发方式也是可以的，毕竟收悉的人比较多实施成本较低，DDD对团队的设计和技术要求度都比较高，在没有足够的能力支持下，所带来的问题可能会比传统的开发方式的问题更多。