Каков практический способ моделирования таблиц поиска в Domain Driven Design (DDD)?

Ответ 1

Вы можете взглянуть на концепцию Разделение запроса команд. Я бы не стал беспокоиться о типизированных репозиториях для значений поиска, но я бы, вероятно, использовал классы типа DTO для наборов данных и т.д.

Вы можете потратить некоторое время на чтение блога Грега Янга, начиная с этого до настоящего времени. Он не говорит о конкретном заполнении данных поиска, но часто говорит о том, что не обрабатывает функции чтения/отчетности вашего приложения с помощью типизированных методов в репозитории.

Ответ 2

Использование DDD У меня есть нечто похожее на следующее:

interface IAddressService
{
  IList<Country> GetCountries ();
  IList<State> GetStatesByCountry (string country);
  IList<City> GetCitiesByState (string state);
  // snip
}

Страна, государство и город - это объекты ценности, которые поступают из таблицы поиска в базе данных.

Ответ 3

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

Ответ 4

Вы читаете неправильную книгу, если хотите узнать, как делать DDD, не усложняя ее.: -)

Самое простое решение, которое вы предлагаете, прекрасно, если оно соответствует вашим потребностям. Инкапсулирование адресных данных в бизнес-объектах может быть таким же простым или сложным, как требует ваше приложение. Например, объект State имеет отношения "один ко многим" с округом, поэтому Employee действительно просто нужно ссылаться на графство, если вы решили его моделировать. Я бы представил только такую ​​сложность, если это необходимо.

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

Ответ 5

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

Цитата из статьи, когда ее спрашивают, следует ли моделировать страны как объекты или объект ценности:

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

Он предложил другой подход, чтобы ввести новое понятие под названием AvailableCountry:

Эти доступные страны могут быть объектами в базе данных, записи в JSON, или даже просто жесткий код в вашем коде. (Это зависит от имеет ли бизнес легкий доступ к ним через пользовательский интерфейс.)

<?php

final class Country
{
    private $countryCode;

    public function __construct($countryCode)
    {
        $this->countryCode = $countryCode;
    }

    public function __toString()
    {
        return $this->countryCode;
    }
}

final class AvailableCountry
{
    private $country;
    private $name;

    public function __construct(Country $country, $name)
    {
        $this->country = $country;
        $this->name = $name;
    }

    /** @return Country */
    public function getCountry()
    {
        return $this->country;
    }

    public function getName()
    {
        return $this->name;
    }

}

final class AvailableCountryRepository
{
    /** @return AvailableCountry[] */
    public function findAll()
    {
        return [
            'BE' => new AvailableCountry(new Country('BE'), 'Belgium'),
            'FR' => new AvailableCountry(new Country('FR'), 'France'),
            //...
        ];
    }

    /** @return AvailableCountry */
    public function findByCountry(Country $country)
    {
        return $this->findAll()[(string) $country];
    }
}

Итак, кажется, что есть 3-е решение, которое должно моделировать таблицы поиска как объекты и сущности значения.

BTW убедитесь, что вы проверили раздел комментариев некоторые серьезные обсуждения о статье.