Проектирование на основе доменов (DDD): проблема домена или инфраструктуры

Question

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

Упрощенный пример описания домена:

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

"Пользователь хочет изучить веб-страницу и определить, появляется ли фраза"lorem ipsum"и в каком месте".

Мы будем использовать Selenium в качестве базовой технологии для подбора фразы.

Перед погружением в DDD я бы создал класс, как показано ниже (Python ниже, но язык не должен иметь значения):

class Page:
def __init__(self, url, environment, driver):
    self.environment = environment
    self.url = url
    self.driver = driver    // Selenium Driver


def contains_phrase(self, phrase):
    self.driver.get(self.environment.url + self.url_suffix)  // Selenium Command
    ...

Эта сущность теперь зависит от селена и больше не является чистым объектом (POCO, POJO и т. Д.). Это не правильно для меня в DDD.

Насколько я понимаю, выражения селена также не принадлежат слою службы приложений, так как это приведет к раздуванию класса / метода, а уровень обслуживания в идеале должен быть тонким.

Принадлежит ли это тогда на уровне инфраструктуры? Очень похоже на хранилище с постоянным кодом, живущим там. Что-то вроде:

class PageAutomator:
...
def does_page_contain_phrase(self, page, phrase):
    self.driver.get(self.environment.url + self.url_suffix)  // Selenium Command

Это звучит как правильное направление? И если это так?:

Это означает, что сущность Page начинает стремиться к анемичной модели и становится простым DTO. Если так, то эта сущность даже необходима больше?

Является ли приемлемым для уровня службы приложений прямой вызов уровня инфраструктуры и выполнение какого-либо действия (для выполнения варианта использования) без участия каких-либо объектов (и, следовательно, домена) вообще? Даже если я буду больше использовать сценарий Transaction Script, я понимаю, что функциональность Selenium все еще не должна существовать в домене?

Или (и я новичок в DDD) я полностью ухожу, и в этом случае любые советы или предложения приветствуются.

Спасибо

Answer 1

Поиск строки внутри HTML не является бизнес-логикой, поэтому дизайн, управляемый доменом, здесь не должен применяться.

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

"Служба поиска" была бы проблемой инфраструктуры, если существует необходимость в абстрагировании от конкретной реализации Selenium или возможности повторного использования в приложениях. Если в этом нет необходимости, это будет сервис / утилита для конкретного приложения.

Answer 2

Насколько я понимаю, выражения селена также не принадлежат слою службы приложений, так как это приведет к раздуванию класса / метода, а уровень обслуживания в идеале должен быть тонким.

Да вы правы. Выражения Selenium должны оставаться внутри Инфраструктуры, поскольку они зависят от технологии.

Это означает, что сущность Page начинает стремиться к анемичной модели и становится простым DTO. Если так, то эта сущность даже необходима больше?

Если домен анемичен (пожалуйста, прочитайте "просто"), то модель также будет анемичной.

Анемия имеет смысл, когда мы рассматриваем часть приложения "Писать", когда поведение остается в доменных службах, когда оно должно оставаться внутри Агрегата.

Если так, то эта сущность даже необходима больше?

Если ваша вещь имеет продолжительность жизни (у нее есть личность; она создается, модифицируется и затем умирает), тогда да, сущность необходима. Если поведение отсутствует (поскольку домен простой), у вас может быть элемент CRUD, а не полноценный агрегат DDD. Вы можете принимать другие стратегические или тактические решения DDD (такие как ограниченный контекст и контекстные карты).

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

Да.