Доменный Управляемый Дизайн и роль класса фабрики

, Но то, что не ясно мне, - то, где фабрика "слой" находится с архитектурой DDD? Фабрика должна звонить непосредственно в репозиторий для получения его данных или сервисной библиотеки?

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

Как правило, существует по крайней мере три источника данных, которые используются в качестве входа в фабрику для конструкции объекта области: вход от UI, результатов запросов от персистентности и доменно-значимых запросов. Таким образом для ответа на конкретный вопрос репозиторий использовал бы фабрику.

Вот пример. Я использую шаблон Разработчика Holub здесь. Редактирование : игнорируйте использование этого шаблона. Я начал понимать, что это не смешивается слишком хорошо с фабриками DDD .

// domain layer
class Order
{
    private Integer ID;
    private Customer owner;
    private List<Product> ordered;

    // can't be null, needs complicated rules to initialize
    private Product featured; 

    // can't be null, needs complicated rules to initialize, not part of Order aggregate
    private Itinerary schedule; 

    void importFrom(Importer importer) { ... }

    void exportTo(Exporter exporter) { ... }

    ... insert business logic methods here ...

    interface Importer
    {
        Integer importID();
        Customer importOwner();
        Product importOrdered();
    }

    interface Exporter
    {
        void exportID(Integer id);
        void exportOwner(Customer owner);
        void exportOrdered(Product ordered);
    }
}

// domain layer
interface OrderEntryScreenExport { ... }

// UI
class UIScreen
{
    public UIScreen(OrderEntryDTO dto) { ... }
}

// App Layer
class OrderEntryDTO implements OrderEntryScreenExport { ... }

Вот то, на что мог бы быть похожим OrderFactory:

interface OrderFactory
{
    Order createWith(Customer owner, Product ordered);
    Order createFrom(OrderEntryScreenExport to);
    Order createFrom(List<String> resultSets);
}

логика для представляемого продукта и поколения Маршрута входит в OrderFactory.

Теперь вот то, как фабрика могла бы использоваться в каждом экземпляре.

В OrderRepository:

public List<Order> findAllMatching(Criteria someCriteria)
{
    ResultSet rcds = this.db.execFindOrdersQueryWith(someCriteria.toString());
    List<List<String>> results = convertToStringList(rcds);

    List<Order> returnList = new ArrayList<Order>();

    for(List<String> row : results)
        returnList.add(this.orderFactory.createFrom(row));

    return returnList;
}

На Вашем прикладном уровне:

public void submitOrder(OrderEntryDTO dto)
{
    Order toBeSubmitted = this.orderFactory.createFrom(dto);

    this.orderRepo.add(toBeSubmitted);

    // do other stuff, raise events, etc
}

На Вашем доменном слое, модульный тест, возможно:

Customer carl = customerRepo.findByName("Carl");
List<Product> weapons = productRepo.findAllByName("Ruger P-95 9mm");
Order weaponsForCarl = orderFactory.createWith(carl, weapons);

weaponsForCarl.place();

assertTrue(weaponsForCarl.isPlaced());
assertTrue(weaponsForCarl.hasSpecialShippingNeeds());

, Где делает фабрику, вписывается в следующую платформу: UI> Приложение> Domain> Сервис> Данные

Domain.

кроме того, потому что фабрика является единственным местом, допускал создание объекта would'nt, Вы получаете циклические ссылки, если Вы хотели создать свои объекты в Ваших данных и уровнях служб?

В моем примере, все зависимости вытекают от начала до конца. Я использовал Принцип Инверсии Зависимости (ссылка PDF) для предотвращения проблемы, о которой Вы говорите.

, Если роль класса фабрики для создания объекта затем, что имеют преимущества уровень служб?

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

В примере я набросал здесь, я предполагаю, что придумывающий Маршрут для Порядка включил бы несколько объектов области. OrderFactory мог делегировать к такому сервису.

BTW, иерархией, которую Вы описали, должен, вероятно, быть UI> Приложение> Domain Services> Domain> Инфраструктура (Данные)

, я задал много вопросов и ценю любой ответ. Какой недостаток i'am является примером приложения, который демонстрирует, как все слои в домене управляемый дизайн-проект объединяются... Есть ли там что-нибудь?

Применение Domain Управляемый Дизайн и Шаблоны Jimmy Nilsson являются большим комплиментом Eric Evans Управляемый Доменом Дизайн . Это имеет много примеров кода, хотя я не знаю, существует ли акцент на разделение на уровни. Разделение на уровни может быть хитрым и является почти темой, отдельной от DDD.

В книге Evans, существует очень небольшой пример разделения на уровни, Вы могли бы хотеть проверить. Разделение на уровни является шаблоном предприятия, и Martin Fowler записал Шаблоны Архитектуры приложений для предприятия , который Вы могли бы найти полезным также.