Лучшие совокупные корни и предложения репозиториев данных

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

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

Customer (Has Data Repository)
    CustomerAccount
    CustomerAccountPerson
    CustomerOptions
    CustomerCustomField
    CustomerCustomFieldData
    CustomerFile
    CustomerNote
    CustomerLoginLog
    ..... and more
Order (Has Data Repository)
    OrderLineItem
    OrderStatusLog
    OrderFlag
    OrderOutsourcing
    ..... and more
Lead (Has Data Repository)
    LeadNote
    LeadSource
    LeadStatus
    LeadStatusLog
    ..... and more
Invoice  (Has Data Repository)
    InvoiceOrder
    InvoicePayment

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

Единственная причина, по которой я разделил его, заключается в большом количестве подтаблиц/элементов в хранилище данных о клиентах и ​​заказах.

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

Заранее спасибо.


c# entity-framework asp.net-mvc aggregateroot
person 99823    schedule 08.03.2013    source источник
comment
ищите статьи о ограниченных контекстах, например. msdn.microsoft.com/en-us/magazine/jj883952.aspx   -  person qujck    schedule 08.03.2013
comment
это отличная статья   -  person 99823    schedule 08.03.2013
comment
этот курс очень хорош, но недостаточно глубок, чтобы ответить на все ваши вопросы (но вы можете получить его бесплатно!) pluralsight.com/training/courses/   -  person qujck    schedule 08.03.2013
comment
Привет @qujck - я действительно смотрел этот курс, пока печатал этот вопрос! хаха!! Забавно...   -  person 99823    schedule 08.03.2013

Ответы (1)


arrow_upward
2
arrow_downward

Невозможно сказать, не зная ваших вариантов использования.

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

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

Если вы пытаетесь использовать DDD (хорошо это или плохо), то ваш дизайн не должен зависеть от базовой технологии данных и макета таблицы. Кто сказал, что вам нужно использовать СУБД?

Основополагающей книгой по DDD является, конечно же, «Дизайн, управляемый доменом» Эрика Эванса, в котором содержится много контекста, который обычно теряется, когда люди начинают культировать DDD.

Также часто рекомендуется книга Джимми Нильссона «Применение предметно-ориентированного дизайна и шаблонов», но лично я не нахожу ее очень хорошей.

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

Я предлагаю прочитать прекрасную книгу Мартина Фаулера "Шаблоны архитектуры корпоративных приложений" - она ​​охватывает более широкую область, чем книги по DDD, и предлагает множество хороших подходов к управлению поведением приложения, а также охватывает все уровни приложения, от серверной части до графического интерфейса.

person Zdeslav Vojkovic    schedule 08.03.2013
comment
спасибо, я все еще новичок в DDD, и ваши комментарии пролили больше света на мои первоначальные вопросы. - person 99823; 08.03.2013
comment
спасибо за ваши предложения, я обязательно проверю их - просто любопытно, что, по вашему мнению, определяет систему, которой действительно нужен DDD? Мне очень интересно ваше понимание этого - person 99823; 08.03.2013