对领域驱动设计DDD（Domain-Driven Design）的理解

软件工程出现以来，人们一直在寻找一种简洁的系统组织方式及交互方式。

传统的系统设计是命令式交互，系统对外提供了哪些操作命令，即系统对外提供了哪些接口。系统的设计是围绕着接口进行的，对接口的实现就是对这些命令的实现，用户通过接口来修改系统的状态（包括系统中存储的数据）。

对于非编程人员来说，只能看到系统所提供的接口，“看不到”系统内部的实现。系统分析和设计是分开的，导致需求和成品非常容易出现偏差，两者相对独立，还会导致沟通困难。DDD 则打破了这种隔阂，领域模型概念统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。

DDD提供了一种很好的现实世界对系统的投影方式，DDD中的领域对象就对应着现实世界的人。DDD的出现实际上减轻了编程人员的负担，它让非编程人员（产品、测试）也可以很方便的理解系统的架构，可以让更多的人参与到系统的设计工作当中来，甚至产品经理都可以直接进行初版的系统设计，但是它增加了系统内的耦合（领域对象之间的耦合肯定高于Service之间的耦合）。

比如，要做一个抽奖系统，那么系统里就需要这些“人”：

• 记录抽奖活动基础信息的工作人员
• 抽奖的工作人员
• 发放奖品的工作人员
• 中奖播报的工作人员

如果在设计过程中发现某个“人”的职责太多，还可以对这个“人”进行拆分，如果可以从“记录抽奖活动基础信息的工作人员”中拆出一个“记录抽奖活动奖品基础信息的工作人员”。