微服务与DDD的流行可以说是一个互相促进的过程：领域驱动设计中的限界上下文解决了微服务划分的难题，微服务为限界上下文提供了合适的物理承载。当我们已经确定了应用系统的限界上下文，采用微服务是一个不错的选择，但前提是限界上下文的划分是合理的，而这取决于对领域问题的充分了解和对应用需求的深入理解。
领域问题往往是复杂的，看清问题的本质是需要花费时间的。只有当对需求有充分的了解时，才具备划分限界上下的条件。我们经常遇到的问题是，刚开始理解的需求，往往不是最终需求，经常需要与用户（领域专家）反复确认和交流，才能逐渐靠近最终需求。因此，试错过程是不可避免的，如果这时就使用微服务架构，可能导致顾此失彼。
微服务架构的技术复杂度高，在项目前期就使用微服务架构，可能会陷入业务和技术双线作战的被动局面。因此，在项目初期，当需求处于验证阶段时，可以使用单体应用承载多个限界上下文，这样有利于项目的迭代验证，当需求趋于稳定，再使用微服务架构进行生成环境的实现。
需要说明的是，很多使用微服务构建的应用并没有按照限界上下文划分原则进行设计，这种情况下，所构建的应用可能只是分布式单体应用，当一个微服务失效，会导致整个应用的崩溃。
更多的内容可以参考《领域驱动设计.Net实践》。