Никита Маслов «Простая архитектура»

[@БогданГуківський]

Когда возникает мысль, что агрегаты абсолютные враги производительности - нужно перечитать книги по ДДД, так как есть вероятность, что понимание этой концепции не верно. Важно осознать - что агрегаты, это не логическая группа сущностей, а граница строгой консистентности. Иногда это совпадает, но ДАЛЕКО не всегда, и игнорирование этого приводит к созданию излишне больших агрегатов и мыслей о частичной работе с ними. Проводить запись не поднимая весь агрегат - ошибка противоречащая бизнесу, так как нарушает консистентность. А если не нарушает - значит, вероятно, границы агрегата определены неверно и стоит думать о его редизайне. Да, крайне сложно выделить агрегаты так, чтобы не возникало даже небольшой избыточности для всех возможных операций, но большой избыточности обычно легко избежать. Но с другой стороны, агрегаты очень сильно повышают возможности масштабирования хранилища и снижают требования к его транзакционным возможностям, так как оптимальным для конкретной доменной задачи, делят данные на транзакционные области. А вот читать агрегаты частично - вполне допустимо и ничему не противоречит, это ваша модель чтения, которая и вовсе может быть в отдельной базе данных, а может быть и в одной просто проекцией агрегатов (например. SQL View).

[@БогданГуківський]

Простота, явность, отсутствие лишних преждевременных обобщений, изоморфность с требованиями, отсутствие рефлексивной магии, отказ от автомапера и медиатора - мое почтение, очень радостно что сообщество к этому приходит. Использование атрибутов - не так и плохо с точки зрения производительности, нужно порядка 300нс, на его получение, что не звучит проблемно, а дальше нужно смотреть по обстоятельствам, что будет лучше, атрибут или свитч. С исключениями согласен абсолютно. Очень грустно, что в С# нет нативной поддержки DU.

[@klimovDev]

Linq2Db говорит о том, старые проекты в организации и от них не избавиться и приходится извращаться и работать с тем что есть. Linq2Db тяжелая обвязка. Почему бы ее не заменить Dapper-ом раз уж нравится логику класть в бд. И код почище и легковесный вариант. С другой стороны, если не нравятся анимичая модель, то никто не мешает использовать "ричабл" модель. При грамотном разделении приложения на слои проблем будет в разы меньше. Лично мне более близка модель, когда бд выступает лишь как деталь(хранилище). Но даже и в этом случае мне ничего не мешает, для более тяжелых запросов, упаковать выборку в хранимку и вызывать ее через EF.

[@shaqull]

Со всем почти согласен, кроме маниакальности в попытке определения "что такое бизнес логика". Как это помогает решать проблемы в реальных приложениях? Что произойдет если я буду делать проще, как советует докладчик, и не использовать спецификации (или скорее использовать их как расширение над IQueryable, который выставлен наружу, как докладчик не советует)?

[@DimonSmart]

Спасибо за доклад. Многие мысли поддерживаю. Накину чуток про простоту. Главное соблюсти тонкую грань между простотой и примитивность. Чуток поясю. Если вы думаете что в будущем вам что-то понадобится, то естественно не надо сразу бросаться это все делать, НО! лучше сразу подумать и делать так чтобы не препятствовать будущем расширениям. В городской архитектуре такого полно. Построили дом не выбирая места, просто где монетка упала. А потом через х лет продлили дорогу и оказывается что дом стоит как раз посреди дороги и его надо сносить. Но на начальном этапе никто не машел немного подумать и построить дом так чтобы он не мешал будущему расширению..

[@TbIPDblM]

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

[@ГеоргийВолков-и2б]

public static string ToDescription(this ColorEnum EnumValue) Через extension метод тип задается явно. Про медиатор, есть расширение в студии чтобы было удобно искать handler. А так решение класть request и handler в одну папку, тогда уж лучше заменить тем, чтобы класть их в один файл, тогда переход с контроллера будет в один клик вообще

[@НатаниэльДампо]

Я так делал 10 лет. Надоело. Становишься рабом БД , вместо ооп, кучи мутантов объектов, бизнес логика это логика доступа к бд.

[@БогданГуківський]

Трилемма ДДД интересная концепция, но обычно превращается в дилемму на практике. Почему? Жертвовать производительностью в реальных системах редко уместно, особенно учитывая размер предполагаемых жертв. Выбор же между полнотой и чистотой можно сделать довольно красиво в пользу полноты, поделив доменную модель на чистую и нечистую зоны. От этого не потеряем в тестабилити (главном профите, получаемом от чистоты) для чистой зоны и не потеряем полноты всего домена.

[@mt89vein]

Забавно как основные постулаты которые заявлены в начале доклада сыпятся с каждым новым слайдом и каждым новым вопросом :)

[@xeleos]

А как реализован UserId?

[@mikhaildervel1561]

Почему так тихо?

[@alexanderqwerty]

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

[@bananasba]

Не видел номально реализованных спецификаций, написал свою.