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

Question

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

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

В идеале список кодов должен быть в Java или Groovy, но что-то подобное (например, C#).

Answer 1

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

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

Edit:

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

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

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

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

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

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

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

Answer 2

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

Возможно, Domain Driven design Step by Step даст вам несколько ответов.

Answer 3

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

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

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

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

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

Answer 4

Возможно, это выступление Джимми Богард содержит то, что вы просите

https://github.com/jbogard/presentations/tree/master/WickedDomainModels