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

Question

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

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

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 

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

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

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

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

Answer 1

Невозможно сказать, не зная случаев использования.

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

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

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

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

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

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

Предлагаю прочитать отличную книгу Мартина Фаулера «Шаблоны архитектуры корпоративного приложения» - она ​​охватывает более широкую область, чем книги DDD, и предлагает множество хороших подходов для обработки поведения приложения, а также для покрытия всех слоев приложения, от внутреннего до GUI ,