洋葱架构和域隔离

之所以称之为洋葱架构是因为类型洋葱——拥有多层且包含一个核心。外层依赖内层，但内层感知不到外层。有点像经典洋葱层架构实体，但不同地是洋葱架构强调核心部分是完全独立地，不依赖任何对象。这意味着领域模型地核心元素应该和其它元素隔离，这是非常重要的一点。

👆是DDD的架构图，核心是Entities（实体）、Value objects（值对象）、Domain events（领域事件）和Aggregates（聚合根）。外层是资源库（Repositories）、工厂（Factories）和领域服务（Domain services）。应用服务（Application services）在其外层，UI是最后一层。数据库属于哪部分？所有的数据库操作（ORM或者其它形式）都分装在Repositories中。实体、值对象、领域事件和聚合根是最基础的，他们能够互相引用，例如聚合根可以引用值对象，值对象也可以引用聚合根。但是这不适用于其它对象，如资源库和工厂。类似的，资源库、工厂和领域服务可以相互感知，且他们也可感知到四个基础元素，但是并不能引用应用服务。

为什么隔离如此重要？为什么将领域模型划分为四个核心要素呢？四个核心要素的关注点不同，实体、值对象、领域事件和聚合根承载了应用最核心的部分——业务逻辑，但他们并没有囊括所有的业务逻辑。资源库和工厂也会保留一些业务逻辑，但四个核心要素是暂大部分的。在这种情况下，将他们职责进行划分是至关重要的。实体和值对象只负责领域逻辑，这意味着它不会关注持久化或者如何创建之类的问题，这两个操作应该是资源库和工厂的责任。他们也不应关心数据库表或列如何存储的问题，也就是说数据映射是不该出现的。责任划分越清晰，后期扩展就越顺利。

public class Product{
    public String name;
    public String getName(){
        return name;
    }
    protected Product(){
    }
    public Product(String name){
        name= name;
    }
}

👆我们可以引入一个无产构造函数来满足对象关系映射，因为这对领域问题的影响微乎其微。或者可以直接创建新的ProductDto专门用来持久化，当然dto可以用作UI层的数据传输。

• 简洁的领域模型
• 合适的责任分离
• 处理ORM副作用

之后的章节将围绕上面三点进行实践。