Существует ли богатый пример модели предметной области?

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

Может быть, Domain Driven Design Step by Step даст вам несколько ответов.

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

В доменно-ориентированном проектировании Теоретически вы создаете свои объекты данных так же, как и любой другой класс, и рассматриваете базу данных как просто слой сохранения. С точки зрения непрофессионала, база данных - это всего лишь контейнер для хранения, и вам все равно, КАК хранятся объекты, только то, что они хранятся каким-то образом. Это устраняет рассогласование импеданса, и у вас на одну проблему меньше. На практике, однако, вы все равно должны знать, как хранятся объекты, и могут возникнуть проблемы с производительностью, когда 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, таблицу адресов и таблицу Company с множеством взаимосвязей между их. Однако это сильно отличается от того, как программист видит этот объект. Программист видит в нем экземпляр объекта Person с 4 параметрами, одним из которых является ICollection . Это не очень хорошо согласуется со структурой таблицы базы данных, отсюда «несоответствие импеданса», или, говоря языком непрофессионала, разница в компоновке между реляционной моделью и объектной моделью.

При проектировании, ориентированном на предметную область, я должен быть в состоянии сделать это:

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

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

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

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

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

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

Person.groovy:

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

Membership.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()
}

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

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

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