Что мы называем этими типами объектов, которые используются в модели предметной области в DDD?

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

Пожалуйста, прочтите ниже ..

Мы используем Domain Driven Design с шаблоном CQRS. Ниже показано, как была разработана модель предметной области.

введите описание изображения здесь

P.S Не связано, но для вашей информации, наше приложение использует ASP.NET MVC, а контроллер взаимодействует с уровнем обслуживания. DTO (объекты передачи данных) передаются в / из контроллеров MVC, чего нет на приведенной выше диаграмме.

Проблема в том, что мы неправильно используем ValueObject. Согласно определению Мартина Фаулера наши ValueObject не являются истинным представлением ValueObject. http://martinfowler.com/bliki/ValueObject.html

Например, у наших ValueObjects есть личность.

public class NoteValue 
{
    public int Id { get; set; }
    public string NoteName { get; set; }
    public string NoteNumber { get; set; }
    public DateTime NotExpiry { get; set; }
}

Эти объекты ValueObject просто переносят данные между командами, AggregateRoots и объектами домена. Например, AggregateRoot просто создает объекты ValueObjects на основе объектов домена и возвращает эти объекты ValueObject на уровень команд.

Ниже представлена ​​не полная реализация. Просто простой пример, демонстрирующий взаимодействие

Метод расширения AggregateRoot:

 private static IList<NoteValue> ToValueObject(this ICollection<Note> source)
 {
    var values = new List<NoteValue>();
    if (source != null)
         source.ForEach(i => values.Add(i.ToValueObject()));

    return values;
 }

AggregateRoot:

 Public IList<NoteValue> GetNotesValues()
 {
     return this._notes.ToValueObject();        
 }

Команда:

  var motesValues = notesAggregate.GetNotesValues();

Мы изо всех сил пытаемся найти подходящее название для этих так называемых «ValueObjets». Они тоже не кажутся DTO, и мы также хотим иметь возможность отличаться от DTO, которые используются на уровне Services. В частности, мы хотим знать подходящее имя, которое мы можем вызывать для этих типов объектов (ValueObjects). Любые мысли приветствуются.


cqrs domain-driven-design value-objects aggregateroot domain-model
person Spock    schedule 12.12.2012    source источник
comment
Почему вы вообще конвертируете между Note и NoteValue? Почему бы просто не предоставить объект Note напрямую инкапсулирующей службе приложения (что, я думаю, вы называете командой)?   -  person eulerfx    schedule 12.12.2012
comment
Почему у вас есть и агрегированный корень, и репозитории? Обычно, когда вы начинаете думать в духе агрегированных корней, репозитории имеют тенденцию либо исчезать, либо сливаться с AR.   -  person Mark Seemann    schedule 13.12.2012
comment
Хотя вы утверждаете, что это связано с DDD, все, что я вижу, - это архитектура инфраструктуры. Где модель предметной области? DDD - это моделирование предметной области, а не какой-то конкретный вид архитектуры. Шаблоны в синей книге - это просто (хорошие) предложения - вам не обязательно применять их все.   -  person Mark Seemann    schedule 13.12.2012
comment
По сути, архитектура в стиле CQRS имеет тенденцию рассматривать команды как автономные сообщения (DTO), которые затем обрабатываются CommandHandlers. Я не говорю, что это единственный способ использовать CQRS, но из приведенной выше диаграммы мне кажется, что эти две роли (Commands и CommandHandlers) были объединены в вашей роли Command. Моя интуиция подсказывает мне, что это вызывает проблемы.   -  person Mark Seemann    schedule 13.12.2012
comment
@eulerfx, извини, не успел вернуться. Я много читаю, особенно у Марка есть действительно хорошие моменты, на которые мне нужно обратить внимание. Что касается преобразования домена (например, примечания) в значение (например, NoteValue) - когда репо возвращает объект домена, в некоторых случаях AR не нужен полноценный объект домена. Вот почему мы конвертируем DO в промежуточный объект (VO), который содержит только необходимые нам свойства.   -  person Spock    schedule 14.12.2012
comment
@MarkSeemann Извините, мне следовало дать более ясный ответ на свой вопрос. Модель предметной области - это в основном объекты домена, AR, правила. Остальное в основном касается вспомогательной инфраструктуры.   -  person Spock    schedule 14.12.2012

Ответы (1)


arrow_upward
3
arrow_downward

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

Дэн Берг Джонссон очень хорошо рассказал о Value Objects: http://www.viddler.com/v/6939b23

Также ознакомьтесь с статьями Вона Вернона по эффективному агрегатному дизайну: http://dddcommunity.org/library/vernon_2011

В общем, DDD (особенно при применении CQRS на архитектурном уровне) требует некоторого времени, чтобы понять. Наберитесь терпения, читайте, учитесь и присоединяйтесь к группе DDD / Cqrs Google

person Dennis Traub    schedule 13.12.2012
comment
спасибо, что поделились этими ссылками. Я также посмотрю на них, чтобы найти возможное решение моего вопроса. - person Spock; 14.12.2012