在微服务实践的过程中，我们经常遇到的一个问题是，究竟怎么样才能更好地进行划分, 一个重要的思想DDD为我们提供了一套很好的解决方案。
我们知道，在微服务还没问世前，我们的程序基本都是单体应用。随着程序越来越庞大，业务越来越复杂，单体应用的不足就显现出来了，很难拆分的代码，难以理解的历史业务，错中复杂，难以理清。有的时候，在处理历史遗留系统的时候，我们简单粗暴的进行接口的拆分，这样导致很多交叉的部分难以分解开，导致陷入泥潭。
DDD的出现就是为了解决这样一个困境，DDD全称是Domain Driven Design，是2003年设计出来的，当时由于缺乏实践的案例，里面的概念也令人难以理解，所以当时并没有流行开来，在当今微服务开始流行起来的时候，很多工程师、架构师发现了这个思想的闪光点，大量运用于微服务的开发过程当中，满足了微服务高内聚、低耦合的要求。
DDD由上至下分为四层，依次为表现层、应用层、领域层、基础设施层，变现层负责给用户展示相应的信息，应用层负责协调应用程序的活动，领域层负责保存和维护业务领域的信息和状态，数据设施层负责数据的传递、数据的持久化等等的工作。以购物车为例子，表现层就是展示给用户看，可以将商品加入购物车，也可以查看购物车内的商品，应用层是负责逻辑的整合，例如清空购物车、检查库存等，领域层是将购物车相关的东西封装到ShoppingCar对象当中，基础设施层是负责把购物车的数据存放在数据库中，以便我们日后使用。
要理解DDD，就要理解DDD的两个重要概念，领域和子域，领域是一个业务范围以及这个业务范围内的软件活动。领域层是具体的业务领域层，是发生业务变化最为频繁的地方，是业务系统最核心的一层，是 DDD 关注的焦点和难点。一个组织有一个大的业务范围，然后划分为组织部门，也会划分为子业务，这就是子域的概念。相应地，对于软件设计，就是把一个大的系统划分为多个模块，即多个子域。业务中所有内容构成了这个业务系统的领域，也就是说它是唯一的。我们开发任何业务系统，首先需要明确业务系统的领域是什么。比如一个在线教育平台，产品包含的业务有学生管理、在线教学、课程等内容，我们可以将这些业务抽象出领域模型，然后根据领域模型的设计进行代码开发的相关工作。
写代码离不开业务，理清业务需求，拆分好领域和子域，这样就能更好的使用DDD思想，以及微服务架构，达到高内聚低耦合的目的。
