Проектирование на основе домена Фабрика DDD

Дизайн, управляемый доменом

Зачем нужен завод

  1. Когда процесс создания сложного объекта или агрегации сложен и раскрывает слишком много внутренней структуры, мы можем использовать фабрики для его инкапсуляции. Объект имеет большое количество обязанностей в своем жизненном цикле, и если сложные объекты несут ответственность за собственное создание, перегрузка обязанностей вызовет проблемы.

  2. Мы разработали модель предметной области для вызова на стороне клиента, но если стороне клиента также необходимо использовать способ сборки этого объекта, она должна знать внутреннюю структуру объекта. Это похоже на то, как вы идете в автошколу, чтобы научиться водить машину, но сначала вы должны изучить принцип работы двигателя. Это очень недружелюбно к разработке на стороне клиента. Во-вторых, знания предметной области (бизнес-правила) в сложных объектах или агрегатах должны быть удовлетворены.Если клиентская сторона собирает сложные объекты или агрегаты, знания предметной области будут просачиваться в код клиентской стороны.

  3. Создание самого объекта может быть серьезной операцией, но создаваемый объект не подходит для выполнения сложных сборочных операций. Смешение этих обязанностей может привести к плохому пониманию и плохому дизайну. Возложение на клиента прямой ответственности за создание объекта запутывает дизайн клиента, нарушает инкапсуляцию собранного объекта или агрегата и приводит к слишком тесной связи между клиентом и реализацией созданного объекта.

Самый важный момент — скрыть детали создания объектов

определение

За создание сложных объектов отвечает слой предметной области, но эта задача не обязательно относится к тем объектам, которые используются для представления модели, они не соответствуют вещам в модели, но берут на себя ответственность слоя предметной области. . Ответственность за создание сложных объектов и агрегатов следует переложить на отдельный объект, который сам по себе может не иметь обязанностей в модели предметной области, но все же является частью дизайна предметной области. Предоставляет интерфейс, который инкапсулирует все сложные операции сборки, не требуя, чтобы клиенты ссылались на конкретный класс объекта, для которого нужно создать экземпляр. Создайте совокупность в целом и убедитесь, что она удовлетворяет установленным правилам.

Заводские дизайнерские точки

1. Каждый метод создания должен быть атомарным и гарантировать, что результирующий объект находится в согласованном состоянии.

2. Вы можете использовать автономную фабрику или метод фабрики в корне агрегата. Когда при создании объекта A в основном используются данные или правила объекта B, то для объекта B можно создать фабричный метод для создания объекта A.

3. В следующих случаях просто используйте конструктор.

  • Класс — это просто тип, он не имеет других подклассов и не реализует полиморфизм.
  • Что заботит клиента, так это класс реализации.
  • Клиент имеет доступ ко всем свойствам объекта, поэтому в конструкторе, доступном для клиента, нет создания вложенных объектов.
  • Процесс строительства прост.
  • Публичные конструкторы должны подчиняться тем же правилам, что и фабрики, должны быть атомарными и удовлетворять всем фиксированным правилам.
  • Не вызывайте другие конструкторы в конструкторах, сохраняйте простоту конструкторов.

4. Параметр фабричного метода должен быть объектом нижнего уровня. Например, чтобы собрать автомобиль, такие объекты, как шины, двигатели и т. д., должны передаваться на более низком уровне абстракции.

Когда мы используем модель корзины покупок для расчетов, мы можем сгенерировать модель заказа из метода заказа модели корзины покупок. Это генерирует агрегацию заказов с помощью фабричного метода агрегации корзины покупок.

Например

В качестве примера возьмем объект форума, чтобы инициировать обсуждение.

public class Forum {
    
    public Discussion startDiscussion(DiscussionId aDiscussionId, Author anAuthor,
                                      String aSubject) {
    
        if(this.isClosed()){
            throw new IllegalStateException("Forum is closed!");
        }
        
        
        Discussion discussion = new Discussion(this.tenant(), this.forumId(),
                                               aDiscusstionId, anAuthor, aSubject);
                                               
        // .. 发布领域事件
        
    
        return discusstion;    
        
    }
    
    
}

Как клиент использует эту модель?

// 由论坛实体生成这个讨论
Discussion discussion = aForum.startDiscussion(this.discussionRepository.nextIdentity(),
new Author("jdoe", "John Doe", "jdoe@gmail.com"), 
"Dealing with Aggregate Concurrency Issues");
// 保存这个讨论
this.discussionRepository.add(discussion);

Фабрика не только инкапсулирует детали создания объектов, но и эффективно выражает общий язык в ограниченном контексте, снижая нагрузку на клиента при создании новых агрегатных экземпляров и гарантируя, что созданные экземпляры находятся в правильном состоянии (соответствующем бизнес-процессам). правила).

Фабрика существует во многих формах, это может быть автономный объект Фабрики, метод фабрики в корне агрегата или служба домена. Фабрики используются не только для создания объектов в начале жизненного цикла, но и для сборки в агрегаты из данных в базе данных в середине жизненного цикла объекта.

Существуют разные понимания DDD, и комментарии пользователей сети приветствуются для совместного обсуждения.

Перейдите на мой личный блог vc2x.com