1.领域模型边界不清晰，无法支持分布式架构：领域建模阶段往往使用面向对象的建模方式，缺少对象间的明确边界。将此方法运用到SOA架构或微服务架构中以后，不同的类将会被分散在不同的服务中，因此需要尽量避免跨越服务边界的对象引用。
比较通用的做法是独立设计、开发每个服务。
对于需要相互协作的服务，由于没有统一领域模型往往会引起数据重复且无法打通，造成严重的烟囱效应。
2.缺乏统一语言，代码难以理解：因为应用开发的不同阶段采用不同的语言，往往经过过滤和翻译转换，因此存在遗漏、曲解的问题，而这些问题直到上线才会暴露。业务逻辑不能从产品团队精准传递到开发团队，有时开发团队开发了一段时间后才发现需求理解有偏差。
3.缺乏合理抽象：在领域复杂度问题上，业务人员不能代替领域专家。没有领域专家的协助，往往无法很好地解决复杂度问题。同时开发团队面对需求增长和变化时，缺乏对业务逻辑的抽象和理解，往往开发一个需求点需要改动多处，容易出错且导致开发效率低、代码可维护性差。
DDD是对面向对象设计思路的升级，它希望通过统一的模型打通业务、需求、设计、开发等不同阶段，用一套模型充分反映领域专家、架构师和开发人员的共识，使应用能够更灵活、快速地响应需求变化，使应用即使变得更复杂也仍然能保持敏捷性。
1.通用语言
DDD的一个核心原则是使用一种基于模型的语言，因为模型是基于领域共同点而建立的，很适合作为通用语言的架构基础。使用模型作为语言的核心骨架，要求团队在进行交流时使用一致的语言，而且代码也是基于该语言模型的，确保团队使用的语言在所有交流形式中保持一致。
2.协作设计
在建立模型时就考虑到应用的设计和开发，开发人员参与到建模工作中，主要目的是选择一个恰当的模型，这个模型能够对应用开发过程有所呈现，这样一来，基于模型的开发过程就会很顺畅。将代码和模型紧密关联会让代码更有意义，且代码能随着模型的调整而调整。
3.支持分布式架构
为了解决分布式应用领域建模的困扰，通过建立统一领域模型，划分子领域边界，使用通用子领域来实现数据同步共享。分布式事务处理也可以通过DDD的聚合机制来维护服务之间的数据一致性。
