Domain Driven Design Теория
ฝัง
- เผยแพร่เมื่อ 14 ต.ค. 2024
- Краткая теория о построении приложение с использованием Domain Driven Design.
Затронуты такие понятия как: Entity, Value-Object, Service, Rich Domain Model, Anemic Domain Model и другие
Благодарности и помощь каналу принимаются:
www.calabonga....
Наши видео доступны и на Дзен:
dzen.ru/calabonga
Можно стать спонсором канала, и вы получите доступ к эксклюзивным бонусам. Подробнее: www.youtube.co...
Блин, такой прикол, позавчера пол интернета перерыл на эту тему, а тут прям видос как под заказ. Огромное вам спасибо за ваш труд)
Что заказали, то и снял. 🤭
Понятное, простое и содержательное объяснение. Спасибо).
Чёткий, простой, приятный комментарий, спасибо.
@@SergeiCalabonga ))
Это то, что давно искал. Большое спасибо!
👍
Одно из самых важных видео для разработчика
А ещё Clean Architecture...
спасибо за видео, давно ждал видео на эту тему) так же вопрос, какие материалы (возможно книги) можете посоветовать по тестированию (юнит, интеграционные и тд)на c# ?
На calabonga.net есть статья на главной странице
Про зависимость слоев некорректно обьяснили, на мой взгляд: слой домена не должен зависеть от каких любо других слоев
У каждого свои взгляды. У нас с Эвансом - один, у вас - другой. 🤣
@@SergeiCalabonga, спасибо за видео! Но тогда почему бы не назвать подход IDD - Infrastructure Driven Design?
@@АртемРащепкин-ф4н в книге так назвается
Респект за видос про DDD искал чего-то такое
sobe.ru/na/calabonganet
Хорошо поданный материал, спасибо. Но я читал, что ещё есть некие аггрегаты, так и не понял в чём отличие от сущностей тех же. Также читал, что репозитории должны быть как раз от этих аггрегатов, что вообще запутало
Всё верно. Есть такие понятия. Материал был создан без упомянутых вами понятий для того, чтобы упростить понимание. Будет вторая часть про DDD.
7:24 Это очень плохая модель архитектуры слоёв. Настоящие слои ("layer") тут это - доменный и так называемое приложение. Остальные два "слоя" это то, что обычно называют "tier", это некие самостоятельные объекты за пределами разрабатываемой программы, с которыми программа обменивается данными в одностороннем или взаимном порядке.
У меня несколько вопросов:
- Кто решил, что "плохая"?
- Кто обычно называет "tier"?
И вообще, такое ощущение, что перепутаны понятия Domain Driven Design и Clean Architecture, которая считается развитием N-tier архитектуры.
Особенно удивила стрелка от крайне левого слоя к крайне правому. Для чего тогда слои, если их можно проигнорить?
Есть в c# value type var p = Point {X, Y}. Меняю значение X и в ответ получаю копию объекта?
Так и работает immutability.
@@SergeiCalabonga Ну это не так. В данном случае у текущей будет изменено значение X. Без копирования. Копия объекта будет создаваться только если идет речь о передаче значения в качестве аргумента функции
@@AlexAlex-ms3bg Вы правы, я поторопился. Если вы у структуры поменяете значение в одном из свойств, конечно, же не будет создана новая копия. Просто в концепции DDD есть такое понятие. А вот что говорит по этому поводу Мартин Фаулер.
If you are using a ValueObject that is mutable, treat it like it is immutable. You may not realize why, but you will save a lot of time and money.
© MartinFowler
wiki.c2.com/?ValueObjectsShouldBeImmutable
20:43: Нафига логику запихивать в класс Entity? Класс должен отвечать за что-то одно. SRP
Rich Domain Model - когда в классе есть поведение (логика)
критическая ошибка. Вы утверждаете что всё должно зависеть от инфраструктуры. Это не так. Все строиться на предметной области, то есть Domain.
Может быть, вы меня неправильно поняли? Или я просто оговорился? Подскажите, на какой минуте где я мог сказать такую глупость?
@@SergeiCalabonga 7:54
@@yava43 да, конечно оговлрился, тем более что стрелки правильно стоят
Не думайн а домен)
Ах, простите оговорился!