Есть ли богатый пример модели предметной области?

Я приведу вам простой пример реального производственного кода:

Person.groovy:

  List addToGroup(Group group) {
    Membership.link(this, group)
    return groups()
  }

Членство.groovy:

 static Membership link(person, group) {
    def m = Membership.findByPersonAndGroup(person, group)
    if (!m) {
        m = new Membership()
        person?.addToMemberships(m)
        group?.addToMemberships(m)
        m.save()
    }
    return m
}

Всякий раз, когда я хочу привязать человека к группе, я могу просто выполнить person.addToGroup(group)

Процедурный код на вашем контроллере будет примерно таким:

def m = Membership.findByPersonAndGroup(person, group)
 if (!m) {
        m = new Membership()
        person?.addToMemberships(m)
        group?.addToMemberships(m)
        m.save()
}

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

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

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

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

Возможно, Дизайн на основе домена шаг за шагом даст вам некоторые ответы.

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

Теоретически в доменно-ориентированном дизайне вы создаете свои объекты данных точно так же, как и любой другой класс, и рассматриваете базу данных как просто слой сохраняемости. С точки зрения непрофессионала, база данных - это всего лишь контейнер для хранения, и вам все равно, КАК хранятся объекты, важно только то, что они каким-то образом хранятся. Это устраняет несоответствие импеданса, и вам не о чем беспокоиться. На практике, однако, вам все равно нужно знать, как хранятся объекты, и могут возникнуть проблемы с производительностью, когда используемая вами ORM пытается выдать сложный SQL-запрос.

Изменить:

Вот пример того, каким в принципе должен быть дизайн, ориентированный на предметную область. Допустим, у вас есть класс Person, например (в C#):

public class Person
{
    public int Id { get; set; }
    public string Name { get; set; }
    public Address Address { get; set; }
    public ICollection<Person> Relatives { get; set; }
    public Company Employer { get; set; }
}

Теперь, в реляционной базе данных, это, вероятно, будет преобразовано в 3 таблицы: таблицу Person, таблицу Address и таблицу Company, с кучей отношений между ними. Однако это сильно отличается от того, как программист видит этот объект. Программист видит его как экземпляр объекта Person с 4 параметрами, один из которых — ICollection. Это не очень хорошо согласуется со структурой таблицы базы данных, отсюда и «несоответствие импеданса», или, говоря простым языком, разница в компоновке между реляционной моделью и объектной моделью.

В доменно-ориентированном дизайне я должен сделать это:

Person person = new Person();
// set each property to something
Database.Save(person);

Теперь объект человека сохранен. Я могу получить его так:

Person databasePerson = Database.Get<Person>(idOfPerson);

И он вернет мой объект Person, как это было до того, как я его сохранил. Таким образом, меня совершенно не волнует, как база данных сохраняет ее, и я не беспокоюсь о несоответствии импеданса. Я просто сохраняю его и извлекаю по мере необходимости.

Хотя это все в теории. На практике вам, вероятно, придется вручную указать «сопоставление» или то, как классы узнают, из какой таблицы/столбца в базе данных получать данные. Это может стать довольно сложным, когда вы пытаетесь сопоставить более сложные типы, такие как словари и другие АТД, а также когда вы пытаетесь извлечь данные из нескольких таблиц в один класс.