Django и доменный дизайн

Question

Я смущен насчет подходов, связанных с доменным дизайном. Из источников в сети я понял, что это способ разделения ваших Domain Objects и Database Objects, но я не понимаю разницы между двумя.

В качестве примера можно привести пример code опроса в учебнике django, есть две модели: Polls и Choice.

Есть ли эти domain level objects или database level objects?

Есть ли необходимость в DDD с ORM?

Если да, то вы можете предоставить хорошую ситуацию, когда вам нужно использовать DDD подход с ORM

Например, это модель

class Polls(models.Model): 
    question = models.CharField(max_length=200) 
    pub_date = models.DateTimeField('date published') 

DDD код подход, который я видел людей, пишущих

class PollService(object): 
    def __init__(self, poll_repository): 
     self.poll_respository = poll_respository 

    def update(self, poll_id): 
     poll = self.poll_respository.fetch_by_id(poll_id) 
     poll.question += '?' 
     self.poll_respository.update(poll) 

#assume that the following code works? 
class PollRepository(): 

    def __init__(self, db): 
     self.db = db 

    def update(self, poll): 
     try: 
      self.db.session().add(poll) 
      self.db.session.commit() 
     except Exception: 
      self.db.session.rollback() 

Правильно ли это? Я вижу много избыточного кода здесь, но люди говорят, что Polls является объектом уровня домена, и он не должен напрямую разговаривать с базой данных?

Есть ли DDD всегда с DDD-репозиционированием? Зачем нам нужен репозиторий DDD, если у нас есть ОРМ

Другой подход

views.py 
def update_poll(poll_id): 
    poll = models.Polls.objects.get(poll_id) 
    poll.question += '?' 
    poll.save() 

Что не так с этим подходом?

Answer 1

Active Record Pattern

Джанго адаптирован к использованию Active Record Pattern, как описано на этой странице Django Design Philosophy.

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

Вы все равно можете использовать этот шаблон более DDD-способом, если вы нажмете больше модели поведения на модель. например в вашем примере, более эффективное использование шаблона будет обернуть линии

poll.question += '?' 

в намерении откровенных методах объекта опроса, так что метод update_poll является:

views.py 
def update_poll(poll_id): 
    poll = models.Polls.objects.get(poll_id) 
    poll.add_question() 
    poll.save() 

Это преимущество разделения бизнес-логики (вдавлено в модель) из логики потока приложений (метод update_poll)

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

Но даже если вы это сделаете, вы по-прежнему используете шаблон активной записи, а не чистый DDD.

Вы спрашиваете: «Есть ли необходимость в DDD с ORM?"

DDD и ОРМ пытаются решать различные проблемы. ORMs обеспечивают удобный способ абстрагирования, как набор записей, ориентированных на мир баз данных в более объектно-ориентированным способом.

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

Многие DDD-системы используют ORM для решения проблем, связанных с восстановлением и сохранением базы данных из базы данных (иногда они обертывают ORM в репозитории по разным причинам), но фокус DDD на моделях доменов и о том, как они подходят для модели рассматриваемой области.

Итак, в вашем примере преимущества DDD трудно понять, так как бизнес-логика настолько проста.

Я рекомендую прочитать источник авторизации в DDD - Domain Driven Design by Eric Evans для языкового агностического обзора подхода и ситуаций, когда он добавляет ценность.

Update

Вы спрашиваете:

Можете ли вы обновить меня один хороший пример, когда с помощью DDD с ОРМ имеет смысл

и

Если мы используем ORM Я думаю, что нет необходимости в DDD-репозитории

Я думаю, что лучший способ подумать об этом - при использовании ORM ORM является репозиторием. Вы просите его о модели, и она возвращает модель. Это цель репозитория. Когда люди завернуть его в классе под названием «хранилище», это, как правило, потому что они хотят, чтобы сделать одну из нескольких вещей:

1. сделать проще внедрить макет хранилища для упрощения модульного тестирования
2. РеФеРаТа конкретных ORM технология используется, чтобы дать возможность изменить ORM позже без необходимости прикасаться к услугам или домен

Это overview of the repository pattern обеспечивает еще один хорошую рецензию шаблона репозитория ддда.