一当我们谈领域驱动设计的时候，到底在谈论什么？

当我们接触到一块未知的业务时，要想搞清楚它，首先需要把问题的边界定义好，针对一个没有边界的问题去找解决方案时无从下手的。这里问题的边界对应到DDD就是领域的边界。
对于某些业务场景的时候，需要不同的角色、不同的事件和命令一起配合才能完成，这里就需要在领域内找到所有的角色（领域实体）、所有的事件（领域事件）、所有的命令（领域服务）；
还需要做更进一步的子问题的拆分，这样可以将问题具体化、更聚焦，对需要找的解决方案也可以更有落地实施的可能性。这里拆分后的子问题对应到DDD就是一个领域范围内的子领域，子领域根据不同的属性、不同业务时期发展的重点等因素，还可以定义为核心域（业务关注的重点）、通用域、支撑域。
划分好不同的子领域，

二分层架构及项目模块依赖

先放张图：

web：对外提供http接口；
api：对外提供rpc接口；
facade：防腐层，对外部接口的请求参数进行校验；
job：任务层，监听其他领域的消息事件、当前领域的定时任务；
app：业务逻辑层，提供业务服务，包括业务用例的实现、业务流程的编排（将依赖的外部服务和当前系统领域能力进行编排来实现某些业务用例）；
domain：领域实体、值对象等定义，领域能力的实现（单个实体可实现的功能在实体内实现，充血模型）、领域服务的实现（多个实体配合实现的领域能力在领域服务中实现，保持多个实体数据的一致性）、领域事件的定义/实现（当前系统内不同聚合根之间的领域事件可通过EventBus实现、不同系统内领域事件的实现可通过mq消息中间件实现）、领域实体的仓储接口定义（采用仓储模式，仓储的接口在domain定义，仓储接口的实现在repository层，domain通过依赖倒置/反转的方式和repository解耦）；
repository：领域仓储的实现，领域仓储的接口在domain层定义，domain不需要关心具体实现方式，repository的实现可以是数据库（mysql、sql server等）、缓存（redis、memcache、应用内存等）、搜索（es、solr等）；

以上就是我们常用的领域模型设计的系统模块依赖以及不同模块的功能职责。