回到主题，我们要了解的是微服务和DDD到底有什么关系呢?
因为在互联网时代，软件所面临的问题域比以往要复杂得多，这种复杂性来源于不断扩展的问题域自身，也来源于创新变化，以及这种规模性增长所带来的挑战。
然而一个人一个团队，他对复杂的事物的认知是有极限的，面对这种复杂问题唯一的方法就是分而治之。分主要考虑的是如何去分;治意味着分出来的每一个部分要能够独立的运行，能够互相的协作，完成整体的目标，能够一来应对外部变化所带来的冲击。
微服务的缺陷
微服务架构在分和治两个方面都给出了很好的理论指导和最佳实践，那微服务是不是解决复杂问题的银弹呢?其实不然，很多团队在应用了微服务架构来构建他们的系统以后，发现并没有完全解决这种复杂性问题，甚至还带来了一些其他的问题。比如服务并 没有解决复杂系统如何应对需求变化这个问题 ，甚至还加剧了这个问题。当一个需求变化了，需要花大量的精力去识别这个变化影响到了哪些微服务，这些服务的多个团队之间，需要通过无休止的扯皮去决定 哪个服务多一些，哪些服务少改一些 ，然后测试团队还需要做昂贵的这种联调测试，即便如此呢，开发团队依然不放心，还要通过一系列的开关控制，小心翼翼的去做切流，去做灰度发布。
从业务层面来看，微服务架构没有避免这种散弹式的修改。甚至反而加重了他，这是为什么呢?一个重要的原因是得微服务架构在分的纬度考虑的并不全面。
DDD功用
当我们去做分的这种工作的时候，具体拆分详见我的另外一篇文章《微服务的拆分姿势》，需要考虑哪些维度呢?我觉得我们至少要考虑三个维度：
- 功能纬度
- 质量纬度，比如性能，可用性
- 工程纬度
微服务对第2个给出了很好的指导，对第3个也给出了一些建议。但是， 对第1个功能纬度只给出来非常有限的指导 ，就是为什么随着微服务的流行，领域驱动设计(DDD)又被重新重视起来的原因。
