领域？

每一个系统都会属于某个特定的领域，比如论坛是一个领域，用户发帖、回帖等都是它的基本功能。同一个领域的系统都具有相同的核心业务，因为他们要解决的问题的本质是类似的。因此，一个领域本质上可以理解为就是一个问题域。

领域驱动设计？

• 领域驱动领域模型的设计
• 领域模型驱动代码的实现

DDD 的核心是基于对领域的理解去设计系统与具体实现。我们只要保证领域模型的设计是正确的，就能确定领域模型可以解决领域中的核心问题，同理，我们只要保证代码实现是严格按照领域模型的意图来落地的，那就能保证最后出来的代码能够解决领域的核心问题的，这是与传统的开发模式的差异所在。根据业务领域来驱动软件设计，这是领域驱动设计的基本思想。

领域模型的具体落地实现

领域模型的设计最终会要落地到代码实现上，对于 node/egg 应用，可以在原有的 service 层的基础上进一步细分来实现领域驱动设计的模式。

• business 层
  负责具体业务的组装，负责对领域对象的业务逻辑的组装以及权限校验，事务等操作。

• domain 层
  core model 负责领域中领域对象的定义。这里应该使用充血模型，将大部分的业务逻辑放在领域对象中，从而是的领域对象可以很好的解释业务。而上层的 business 层只负责对业务逻辑的组装以及权限校验等操作。当业务变更的时候，需要对应的更新领域对象。
  core repository 作为对象的仓储。 repository 的意义是将领域对象和数据持久化对象之间的关系进行抽象。对于复杂的业务，可能一次业务流程包含对于一个领域对象持久化，读取，再更新，再持久化的过程。持久化的操作本身是不属于领域的一部分的，所以对于这些逻辑都可以封装到仓储，避免污染领域模型。

• infrastructure 层
  基础设施层，包含通用的技术组件可供 domain层和 business层调用，同时包含对于外部依赖的服务的封装。如数据持久化DAL层，外部服务RPC调用，Redis缓存等。