Как лучше всего спроектировать следующий домен

С DDD все зависит от концепций и отношений предметной области (которые НЕ являются отношениями rdbms). ООП также не имеет значения, поскольку это технический подход, в то время как вы используете бизнес-подход (домен). Однако вы будете использовать ООП неявно, потому что это естественный способ моделирования предметной области.

Я не знаю вашего домена, но, судя по тому, как вы описали проблему, я думаю, что там не так много DDD, а есть старое мышление CRUD, замаскированное терминологией DDD. ИТ-специалистам не кажется, что вы идентифицировали соответствующий ограниченный контекст и совокупные корни (AR). Что же могут делать эти сущности (поведение)? Как они используются (варианты использования, в которых они задействованы)?

Когда вы выполняете DDD, вы позволяете домену сообщать вам, какие объекты являются объектами и как они взаимодействуют друг с другом. AR может «указывать» на другой AR через идентификатор, однако контекст и варианты использования имеют большое значение. И у вас может быть несколько AR, моделирующих одну и ту же концепцию, но в разных контекстах, поэтому не всегда можно использовать только одну учетную запись AR везде.

Не торопитесь и забудьте об ООП, ORM, rdbms и т. д. Сосредоточьтесь только на домене, чтобы правильно понять концепции (они могут быть хитрыми!) и их отношения. Полученный код будет хорошим ООП и, что более важно, хорошим моделированием. После этого беспокойтесь о настойчивости и rdbms.

Изменить

Основываясь на OP и сути комментария, я думаю (я могу только догадываться, так как сейчас не знаю домена), что это вариант использования Lead (Table) Итак, если нет других соответствующих деталей, у меня будет служба или аналогичная, которая возьмет на себя руководство и IEnumerable для выполнения поведения. Вы запрашиваете у репозитория учетных записей учетные записи для потенциальных клиентов, предоставляя критерии соответствия (код города и id_кампании).

Как правило, я предлагаю попытаться проанализировать эти концепции и попытаться переформулировать их отношения, пока вы не будете уверены, что поняли правильное соотношение.

В строгом смысле ООП вы должны использовать ассоциации для описания того, как объекты связаны друг с другом.

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

На самом деле я не знаю, используете ли вы OR/M или нет, чтобы сохранить такой домен в какой-либо базе данных, но если вы делаете это таким образом, вы должны иметь возможность создавать фактические ассоциации и сопоставлять их с таблицами в способ, которым ваша область будет выражена в виде полного объектно-ориентированного программирования:

• У интереса есть свойство «Учетная запись», которое связывает 1 интерес с 1 учетной записью (связь 1:1).

Кроме того, ООП и OR/M, или просто преобразователи данных, лучше работают с искусственными ключами (ключи одного столбца), а не с составными.

Возможно, вы не используете OR/M. Тогда простым решением будет добавление в ваши классы метода, который будет загружать ассоциации под названием «Загрузить» без параметров:

Lead lead = new Lead();
lead.Load();

// Now you can access "Account" association:
lead.Account.Id

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