Непонятки с DDD
Есть следующие классы: - вопрос: зачем переопределили 'public new ValueId<TIdType> Id' в AggregateRoot. EF дуреет.
public abstract class AggregateRoot<TId, TIdType> : Entity<TId>
where TId : ValueId<TIdType>
{
public new ValueId<TIdType> Id { get; protected set; }
protected AggregateRoot(TId id)
{
Id = id;
}
protected AggregateRoot()
{
}
}
public abstract class Entity<TId> : IEquatable<Entity<TId>>, IHasDomainEvents
where TId : notnull
{
private readonly List<IDomainEvent> _domainEvents = new();
public TId Id { get; protected set; }
public IReadOnlyList<IDomainEvent> DomainEvents => _domainEvents.AsReadOnly();
protected Entity(TId id)
{
Id = id;
}
...
}
public abstract class ValueId<TId> : ValueObject
{
public abstract TId Value { get; protected set; }
}
Чё это за хрень?
всего 9 мин. Или хотите Вон Верона и Эрика Эванса - там по часу 
В EF уже из коробки есть ORM, Repo, Unit of fucking work и ag... aghhh... aggregation root
примерчик есть? Там совсем не то.
Чем транзакции не устроили? Собираете изменения по дереву сущностей с этим вашем корнем агрегации (главной сущностью), и сохраняете пачкой. У меня сейчас в приложухе начала 2000-х подобная же хрень происходит. Придумали какой-то домен, хотя всегда это была бизнес-логика (логика бизнес-процессов, для которых создавалось приложение) или ещё как-то. События какие-то у сущностей. Я как-то лет десять назад тоже событие написал у себя в классах бизнес-логики, типа на склад добавился товар - оповестить подписантов. Всё, у меня DDD. Придумали какие-то новые слова для старых вещей, чтобы со сцены дурачкам продавать. Все давно такие или подобные приложения писали, а тут нашлись чуваки, решившие продать старьё под чуть новым соусом.
Кто знает - работает, кто не знает - множит сущности, запутывает всё, а потом за деньги пытается распутывать - вобщем, зарабатывает на развешивании лапши на уши. Или вот ещё каждый выскочка, даже если ему повезло что-то сделать и он применил какой-то немного не такой подход, бежит навешивать своё имя на это и рассказывать, какой он гуру, и вот у него пачка платных курсов по этой теме.
Сами-то сможете сказать, где в вашем приложении и чем отличается model, domain, business logic и ещё хрен знает что? На собесах такие "назовите 10 отличий хрен-дривен от редька-дривен девелопмент (у меня в шпаргалке под столом так написано)" - "ля, чувак, я и двух не припомню, а ты целыми десятью себе голову забил!".
))
Чем транзакции не устроили?
У вас уже в БД всё промоделировано, а EF дал удобный интерфейс для конвергенции этих двух миров (ООП и БД). Берёте любой объект (таблицу) и сохраняете его изменения и всех их зависимостей по дереву связей как хотите, после чего всё пачкой сохраняете. Чего он там билдинг блокс делает какие-то, непонятно.
Лять, какая херня! А если мне не надо по всему приложению переопределять все возможные операторы сравнения для объектов, приписывать им уникальные айдишники (а что, с БД не устроили?) и прочее, а надо только для части объектво? Всё, у меня не DDD? Вот есть пачка замороченных объектов, я для них написал там все эти сравнения, отслеживание версий объекта и прочее. А для остальных - забил. Что у меня? DDD, MVC, TDD или химера?
А для остальных - забил. Что у меня? DDD, MVC, TDD или химера?
Зная ваши предпочтения, я бы вообще не рекомендовал это смотреть. Ведь всё от неверных или шаманов пытающихся продать свои сказки.
а что, с БД не устроили?
тут есть маленький ньюанс, что ид с БД приходят после создания объекта (записи объекта в базу)
Чтобы подчеркнуть что это не ID объекта
Тоже вот идей особых нет. 
При этом все агрегаты будут иметь одинаковый тип ИД, что вроде не очень хорошо.
И в самом первом видео такого нет, но помню есть еще одно. Скорее ради чего то другого изменили.
Но в данном случае, не имею понятия как написать конверторы для EF, особенно когда отношение много-много.
И не хочет еще что-то EF работать со ссылками на объекты (типа UserId), если есть в агрегате объект, то в таблицу пишет его ИД без проблем, а если в агрегате UserId, то пока не нашел способа записать также ИД для всех вариантов.
а что, с БД не устроили?тут есть маленький ньюанс, что ид с БД приходят после создания объекта (записи объекта в базу)
Ну будете вы генерить айди не там, где храните объект, а там, где создаёте. Смысл? Теперь у вас в БД будут либо таблицы без ключей, либо ключи без генерации, что вообще не свойственно для реляционных БД. Т.е. они как бы уникальные и ключи, но генерятся на стороне - т.е. БД по идее не должна их рассматривать как уникальные ключи, т.к. сгенерены не ей самой были - нет доверия, нужна валидация. Т.е. вводить уже на стороне БД проверку на уникальность при добавлении каждого нового объекта с ключом. А это лишние вычисления. Нахрена, если проще создать уже сразу в БД, которая и позаботится об уникальности?
Вот в моём проекте нет БД, я всё храню в файлах, поэтому и генерю айдишники на клиенте (серверной логики у меня тоже нет). Всё, у меня уже DDD? Правда, я его применяю, не бегая по сцене со своими умными лекциями.
Кстати, непонятно, зачем все эти перегрузки операций сравнения, если у вас есть айди на любой объект? Вам теперь достаточно сравнивать лишь айдишники.
Ну будете вы генерить айди не там, где храните объект, а там, где создаёте. Смысл?
хм, да действительно тяжело объяснить что земля круглая. 
Хотя какое то время назад тоже не имел никаких проблем с генерацией ид на стороне базы. И в каких то случаях может и будет гораздо лучше, так как никакая архитектура не может быть одинаково хороша для всех проектов.
БД по идее не должна их рассматривать как уникальные ключи
как скажем так и рассматривает.
Кстати, говоря, очень толковые ответы попадаются.
И вопросы не обязательно задаются, что-бы получить на них объяснение.
Сам процесс формулирования вопроса и реакция на него может дать очень много полезного.
Иногда бывает, что уже на этапе формулирования вопроса видишь в чём проблема.
назад
список