Комментарии 37
Раз автор приглашает к дискуссии, то мне бы хотелось узнать, каким образом DDD безболезненно ложится на популярную ныне микросервисную архитектуру? Богатую доменную модель можно спроектировать в контексте одного сервиса, а что если логика работы с моделями обслуживается разными сервисами да еще и на разных языках?
Идеально ложится часто: один микросервис — один ограниченный контекст.
Угу, 1 из многих можно без особых проблем. Собственно часто этого даже не замечают :)
С другой стороны, один сервис — много контекстов это классический монолит или "макросервис"
Соглашусь полностью. При этом исхожу
- Из опыта общения с архитектором DataArt Вячеславом Михайловым, разработчиками DodoPizza Евгением Пешковым GraDea и Дамиром Атыгаевым на AgileDays'19. Поднимали вопрос и в принципе все пришли к мнению, что удобнее один ограниченный контекст на микросервис.
- Насколько я помню, Эрик Эванс в своей книге рекомендует в случае слишком сложной модели разделить контекст.
- Один из паттернов декомпозиции микросервисов — по субдомену.
1. один микросервис на несколько контекстов — микромонолит или осколок легаси-монолита. При этом внутри контексты могут общаться через очередь. Такое проще деплоить, проще разрабатывать и тестировать в какой-то мере.
2. несколько микросервисов на контекст — наверное такое тоже может быть, если за этим решением стоят какие-то повышенные требования к безопасности или производительности.
Один из паттернов декомпозиции микросервисов — по субдомену.
"Субдомен" выглядит как синоним "ограниченный контекст" или есть различия?
У Вернона подобласть — идеально выделенный экспертами предметной области ограниченный контекст.
«When using DDD, a Bounded Context should align one-to-one (1:1) with a single Subdomain. That is, when using DDD, if there is one Bounded Context, there is, as a goal, one Subdomain model in that Bounded Context. It may not always be possible or practical to achieve, but where possible it is important to design in that way. This will keep your Bounded Contexts clean and focused on the core strategic initiative.»
Но ведь это же приведет к инфраструктурному оверхеду? Не говоря уже о том, что при неудачном проектировании логика работы с моделью будет размазана по сервисам и концов не сыщешь.
Микросервисы всегда к нему приводят. Можно даже сказать, что в этом их смысл — перенести какую-то часть сложности системы на инфраструктурный уровень.
Пои неудачном проектировании в принципе концов не найдёшь. Если придерживаться принципа "на один контекст один сервис в котором только один контекст" то нечему ращмазываеться, модель не покидает границ контекст-сервиса
И мы ищем докладчиков (еще одного для этого митапа, и вообще для последующих). Давайте дружить и продвигать вместе!
Я, конечно же, регистрацию прошел. Но привкус паранойи остался. Зачем столько личных данных?
Видеозаписи выступлений выкладывать не планируете?
С одной стороны анемичная модель и дешёвое решение — это хорошо, ведь у начинающих программистов появиться понимание нового измерения в программировании — бизнес-объекты. Однако, занимая подобную позицию вы делаете плохо себе же. Нанимая каждый раз более слабого программиста, который может делать примерно то же самое что и вы копипастой, разве у вас найдётся аргумент для бизнеса поискать более сильного сотрудника?
И в следующий раз когда вы подумаете куда идти на интервью, тщательно подумайте что вы, выбираете — компанию нещадно перепродающую ваши скилы, или кому они действительно нужны для решения конкретных задач. В ваших силах помочь такой компании быть лучше, попробовать при этом соразмерные методики и подходы, сформировать сплочённый коллектив, выполнить свою миссию программиста.
Я правильно понял по этим фразам, что вы рассматриваете Domain Driven Design не как средство решения конкретных проблем бизнеса, способное повысить его эффективность, а как средство защиты программистами, его освоившими, своих привилегий (в виде высокой зарплаты и т.п.)?
Если я понял неправильно, то поясните, пожалуйста, что вы на самом деле имели в виду.
Только если вы вырываете данные фразы таким образом из контекста, перевирая смысл.
а как средство защиты программистами, его освоившими, своих привилегий (в виде высокой зарплаты и т.п.)?
встречный вопросы
- Квалификация разработчика перестала стоить денег?
- Вам нравится набирать разработчиков не по их возможностям, а тому как они себя продали на собеседовании?
Разве у нас не честный рынок?
Хотите берите такого человека, хотите увольняйте. А в следующий раз может люди к вам осознанно не пойдут, зная что вы сложных задач не решаете и тушите пожары.
А статья в принципе о том, что в угоду KPI менеджмента программистам приходится тесниться, занимаясь соглашательством и трансформируя практики, занимая выжидающую позицию, не редко в грёзах о полноценном проекте. И что хотелось сказать под конец — было бы не плохо поменьше менеджмента, разобщающих команды и решающего свои интересы.
Всё же в ответе несмотря на жирный текст важны не сами ключевые показатели, а те компромиссы, на которые иногда приходится идти. Вот в этом вопрос — насколько и почему эти компромиссы приемлемы.
Например, мои опасения связанны с тем, что в этом нет полноценного анализа домена, что глубокий рефакторинг никогда не наступит, вся команда может и не знать о связях контекстов, а решение в целом не сможет стать Large-scale structure. Конечно, это лично мои опасения, но возможно приписка [DDD-бичпакет] всё же нужна.
Поискав ещё немного, я понял почему конкретно вы для себя решили этот вопрос таким образом. И это вообще не отменяет элегантности предложенного решения. Уж простите мой догматизм, но риторика поста должна сохраняться.
Хорошего выступления завтра!
Аля, анемичная модель — это антипаттерн, а DDD это передавая практика.
Сюда же — Команды хотят делать инструменты и решения, которые наиболее правильно, быстро и красиво решают бизнес-задачи
Я имел «счастье» разрабатывать проект по этой модели (По Вернону). И это было очень долго и сложно. А сейчас на поддержке — это очень сложно и очень больно.
По факту DDD это некая «красивая» модель, которая не ложиться на реальный мир. Ее постоянно пиарят и докручивают новыми фичами. Аля Event Sourcing, Microservices, теперь оказывается еще и функциональщиной. И каждый раз дают обещания — вот сейчас то точно полетит. Только вот есть проблема. DDD не летит. Никто массово ее не применяет, ни у кого не получается натянуть на реальный мир.
Постараюсь донести основную идею. Не бывает красивой модели разработки в вакууме. Если DDD не ложиться на экономически выгодную разработку — значит это плохая модель.
Я имел «счастье» разрабатывать проект по этой модели (По Вернону). И это было очень долго и сложно. А сейчас на поддержке — это очень сложно и очень больно.
Соглашусь что у Вернона не всё хорошо, он действительно подходит слишком частно к решению. Каждый раз у меня сомнения что рекомендовать первой книгой по DDD. Однако, возможно проблема как раз в том что вы слишком буквально воспринимаете такие книги и статьи, не подходя критически, а принимая как руководство к действию? Со своим коллективом я долго проверял это как эксперимент, делая выводы, корректируя план.
Если DDD не ложиться на экономически выгодную разработку
Любая разработка не выгодна пока не принесла пользу бизнесу. Это инвестиция бизнеса.
в каждой статье про DDD, авторы дорисовывают ореол божественности данной модели разработки.
Заметьте, B7W, что статья не совсем о божественности подхода, а о другом.
Любая разработка не выгодна пока не принесла пользу бизнесу. Это инвестиция бизнеса.
Мне кажется вы что-то совсем странное себе придумали. ПО это лишь средство достижения бизнес цели, а не инвестиция.
Скажите, а вы использовали технические практики только? Как по мне, то без активного, практически ежедневного участия бизнеса в построении модели, DDD и будет долго и сложно. Разработчики будут рисовать модели, перекладывать их в код на уровне своего понимания предметной области, а эксперты к ней привлекаться будут поскольку постольку. На уровне UI требования будут формироваться: "Тут нам нужно табличку с такими-то колонками, а при клике открывается форма с такими-то полями"
Прочитал статью, не понял, а в чём, собственно, "кризис DDD-сообщества"? DDD не получило такого широкого распространения, на которое рассчитывали в сообществе? Или что бизнес не хочет платить за DDD? В общем, чувствую в статье разочарование, но никак не могу уловить, чем именно.
Кризис DDD сообщества