区分Subdomain的必要性
在帮助一个长期合作伙伴构建大规模DDD应用时，我写了一个“xx阶xx步”的体系。也成了很多咱们同事体系性学习DDD的开始。
一年半以后这个团队组织了所有的技术专家和主管让我又讲了一次这个体系。这次我花了一天时间让大家体会问题和解决方案的区别，加入了Subdomain的概念。参加团建时，我问了几个专家和主管他们怎么看之前的设计，得到更多是务实的“赞赏”。其实我并不在意具体落地时的裁剪，但希望白纸黑字时应该明确原委，这也是我为什么拒绝了《领域驱动设计精要》翻译的原因。
我经常用电商的案例让大家快速认识到Subdomain划分的重要性。大浪淘沙之后我们发现淘宝和京东依然是霸主。当年马爸爸嘲笑强哥构建人肉物流网的寓言也并没有发生，反而很多人爱上了京东自有物流的速度。当然站在马爸爸当年对电商问题的认知角度，自建物流是可笑的，毕竟他要解决的核心问题是如何让琳琅满目的中小供应商能够直接对接千千万万的用户，让用户能够更容易的发现适合的商品。
所以从一开始淘宝和京东定义的Core Subdomain就是不一样的，正是问题认知的区别让两家都活了下来，并且活得很好。我们可以看到在线物品展示，吸引消费者方面淘宝一直在引领；而行业里如果你有机会接触电商领域，会发现京东物流系统还是蛮厉害的。
这是我们多年后的今天看到的结果呈现，但其实真正决定命运和格局的确是多年前两家电商对自身核心问题的理解。这个认知驱动出了两家完全不同的成功电商。
很多同学会说这玩意儿是商业模式，也轮不到我们搞研发的参与。我们拿到的都是既定问题了，再识别Subdomain也没啥意义了。这个论断有两方面问题：
• 作为产品和服务的实现者，如果都不参与和关注问题本身的划分及核心子问题的认知，那么你很可能在浪费自己的时间，开发出未来被边缘化，甚至淘汰的系统。这不是危言耸听，在我的最近咨询过程中已经鉴证了很多次，比如在这个移动优先的时代去强化PC应用的技术架构。
• 其次在这个软件应用空前发展的时代，始终抱着所有模块都必须是“自研”，所有代码都必须自己写的思想，毫无疑问只能成为“小作坊”。构建现代的复杂系统已经逐步成为一个生态工程，随着数字化服务的普及，识别哪些领域应该直接外购使用也成为了开发团队的重要能力，构建一个典型的移动应用应该没有人再会去重头写一个二维码扫描模块，而是学会从市场上选择适合的软件包。
那么什么地方应该建，什么地方应该买，应该如何决定呢？这时候我们会发现Subdomain的划分就非常有指导意义了。类似二维码扫描这样的Generic领域显然应该是外购的，而当年京东对电商的理解来看物流系统是要自建的。同样道理还有上次DDD China大会来分享的盒马生鲜，半年时间已经重写了三次核心ERP系统。不去思考问题划分的同学们会觉得盒马疯了，ERP在外部看来是多么成熟的软件包啊~但事实上盒马生鲜的本质就在如何解决生鲜食品的高效配送上，也可以说是一家特殊的物流公司。
小结一下，即使区分问题和解决方案很抽象，划分子问题很烧脑，我们还是必须认识到分析问题本身的重要性和必要性。借用雷布斯的成名句“不要用战术上的勤奋掩盖战略上的懒惰”！