DDD，即Domain drive design领域驱动设计，是随着软件复杂度越来越高，需要结合微服务理念，合理按照业务领域不同进行微服务划分，一张数据库表只对应于某一个微服务中，微服务之间通过API接口调用，比如订单，商品管理等。当某一个功能需要修改，仅需修改对应的微服务。
需要注意的是，DDD通常在系统越来越复杂的背景下产生，对于一个新系统，一开始即采取领域驱动设计，可能并不能简化系统开发，反而增加设计成本。
随着版本不断迭代，用户需求不断变更，系统会越来越复杂，需要调整程序结构而非不停的塞入代码，最终才可能始终获得高质量代码。
软件的本质是真实世界的反映。真实世界是什么样子，我们的软件世界里就会有什么样的对象，真实世界的关系是怎么样的，软件世界也对应怎么样的关系。
单一职责原则即一个软件服务完成一个功能，其他服务与之无关。基于这样的模型，今后如果“付款”模块发生变化，不会影响到“折扣”模块。 如果要增加新的折扣或有不同的折扣，仅需对应修改“折扣”服务。
绘制领域模型时，采用一个一个的小图，即限界上下文，对系统进行拆分，从而做到系统高内聚，微服务化。当对应微服务发生变更，仅需修改对应微服务。因此我们采用领域驱动设计思想进行微服务设计。
因我们的系统处于不断的变更，系统越来越复杂，这时候领域驱动设计才会发挥作用。相反，当系统比较简单时采用领域驱动设计会显得比较麻烦。新项目采用领域驱动设计，增加维护成本，是为了未来能够更好的适应需求的迭代变化。
