Когда разработчики хотят использовать Анемичную модель, они делают несколько хуже себе.
Да, агрегат (и я имею в виду насыщенную модель) становится сложным, у него много обязанностей. Но это в одном слое/уровне или за некоторым фасадом. Агрегат при этом требует соблюдения простых правил, и ответственен только сам за себя.
То есть в определённых границах, насыщенная модель сложна, но и в ней есть место декомпозиции. За этими границами это такой же простой объект, как DbContext или Mapper, или что угодно ещё.
Зато, я верю что работу по Анемичным моделям легче спроектировать и делегировать. Моя работа делать ПО в срок с установленным качеством. Если ваша не продавать софт лично, я не понимаю зачем вам это.
Отдельный разговор, то что большинство примеров АМ не показывают соблюдения инвариантов.
chapuza считаю, вы не совсем понимаете экономическую подоплёку. Что хуже, в ваших рассуждениях изрядный налёт романтизма.
Первоначально нужно понимать кто такие "элитные программисты прошлого" — люди работающие на экономику, а именно на снижение себестоимости производства (назову это временным капиталом). С 70х экономика модифицировалась. Во-первых, IT продукты стали доступны обычному массовому потребителю — программисты часто больше не опора бизнеса, а сам бизнес. Во-вторых, финансовый сектор теперь всё сильнее мультиплицирует экономические эффекты, в т.ч. зарплаты. Именно поэтом труд "формошлёпера" в банке и инженера на заводе не одно и то же.
Ещё более странно то, что этот труд вы сравниваете с менее квалифицированным. Это конечно моё личное мнение, но я думаю разработка всё же на стыке наук, и учиться приходиться непрерывно. Именно это вас определяет, а не то, начинали вы с курсов или престижного вуза.
Те инженеры были элитой, потому что приносили пользу обществу и не гнушались разобраться в чужой области, поговорить с людьми, выстраивать систему не только здесь и сейчас, но и её точки расширения.
Всё же в ответе несмотря на жирный текст важны не сами ключевые показатели, а те компромиссы, на которые иногда приходится идти. Вот в этом вопрос — насколько и почему эти компромиссы приемлемы.
Например, мои опасения связанны с тем, что в этом нет полноценного анализа домена, что глубокий рефакторинг никогда не наступит, вся команда может и не знать о связях контекстов, а решение в целом не сможет стать Large-scale structure. Конечно, это лично мои опасения, но возможно приписка [DDD-бичпакет] всё же нужна.
Поискав ещё немного, я понял почему конкретно вы для себя решили этот вопрос таким образом. И это вообще не отменяет элегантности предложенного решения. Уж простите мой догматизм, но риторика поста должна сохраняться.
Я имел «счастье» разрабатывать проект по этой модели (По Вернону). И это было очень долго и сложно. А сейчас на поддержке — это очень сложно и очень больно.
Соглашусь что у Вернона не всё хорошо, он действительно подходит слишком частно к решению. Каждый раз у меня сомнения что рекомендовать первой книгой по DDD. Однако, возможно проблема как раз в том что вы слишком буквально воспринимаете такие книги и статьи, не подходя критически, а принимая как руководство к действию? Со своим коллективом я долго проверял это как эксперимент, делая выводы, корректируя план.
Если DDD не ложиться на экономически выгодную разработку
Любая разработка не выгодна пока не принесла пользу бизнесу. Это инвестиция бизнеса.
в каждой статье про DDD, авторы дорисовывают ореол божественности данной модели разработки.
Заметьте, B7W, что статья не совсем о божественности подхода, а о другом.
Только если вы вырываете данные фразы таким образом из контекста, перевирая смысл.
а как средство защиты программистами, его освоившими, своих привилегий (в виде высокой зарплаты и т.п.)?
встречный вопросы
Квалификация разработчика перестала стоить денег?
Вам нравится набирать разработчиков не по их возможностям, а тому как они себя продали на собеседовании?
Разве у нас не честный рынок?
Хотите берите такого человека, хотите увольняйте. А в следующий раз может люди к вам осознанно не пойдут, зная что вы сложных задач не решаете и тушите пожары.
А статья в принципе о том, что в угоду KPI менеджмента программистам приходится тесниться, занимаясь соглашательством и трансформируя практики, занимая выжидающую позицию, не редко в грёзах о полноценном проекте. И что хотелось сказать под конец — было бы не плохо поменьше менеджмента, разобщающих команды и решающего свои интересы.
Из опыта общения с архитектором DataArt Вячеславом Михайловым, разработчиками DodoPizza Евгением Пешковым GraDea и Дамиром Атыгаевым на AgileDays'19. Поднимали вопрос и в принципе все пришли к мнению, что удобнее один ограниченный контекст на микросервис.
Насколько я помню, Эрик Эванс в своей книге рекомендует в случае слишком сложной модели разделить контекст.
Один из паттернов декомпозиции микросервисов — по субдомену.
Изменения сами по себе не рождаются, они приходят из какой-то проблемной области. Проблемная область — это область задач, в рамках которой проблемы, требующие изменений в коде, формулируются на одном языке, с использованием одного набора понятий или связанные бизнес-логикой между собой.
Мне показалось, что автор интуитивно подводит к понятию предметно-ориентированного проектирования.
Разве лучший способ декомпозиции микросервисов не ограниченный контекст?
Когда разработчики хотят использовать Анемичную модель, они делают несколько хуже себе.
Да, агрегат (и я имею в виду насыщенную модель) становится сложным, у него много обязанностей. Но это в одном слое/уровне или за некоторым фасадом. Агрегат при этом требует соблюдения простых правил, и ответственен только сам за себя.
То есть в определённых границах, насыщенная модель сложна, но и в ней есть место декомпозиции. За этими границами это такой же простой объект, как DbContext или Mapper, или что угодно ещё.
Зато, я верю что работу по Анемичным моделям легче спроектировать и делегировать. Моя работа делать ПО в срок с установленным качеством. Если ваша не продавать софт лично, я не понимаю зачем вам это.
Отдельный разговор, то что большинство примеров АМ не показывают соблюдения инвариантов.
chapuza считаю, вы не совсем понимаете экономическую подоплёку. Что хуже, в ваших рассуждениях изрядный налёт романтизма.
Первоначально нужно понимать кто такие "элитные программисты прошлого" — люди работающие на экономику, а именно на снижение себестоимости производства (назову это временным капиталом). С 70х экономика модифицировалась. Во-первых, IT продукты стали доступны обычному массовому потребителю — программисты часто больше не опора бизнеса, а сам бизнес. Во-вторых, финансовый сектор теперь всё сильнее мультиплицирует экономические эффекты, в т.ч. зарплаты. Именно поэтом труд "формошлёпера" в банке и инженера на заводе не одно и то же.
Ещё более странно то, что этот труд вы сравниваете с менее квалифицированным. Это конечно моё личное мнение, но я думаю разработка всё же на стыке наук, и учиться приходиться непрерывно. Именно это вас определяет, а не то, начинали вы с курсов или престижного вуза.
Те инженеры были элитой, потому что приносили пользу обществу и не гнушались разобраться в чужой области, поговорить с людьми, выстраивать систему не только здесь и сейчас, но и её точки расширения.
Всё же в ответе несмотря на жирный текст важны не сами ключевые показатели, а те компромиссы, на которые иногда приходится идти. Вот в этом вопрос — насколько и почему эти компромиссы приемлемы.
Например, мои опасения связанны с тем, что в этом нет полноценного анализа домена, что глубокий рефакторинг никогда не наступит, вся команда может и не знать о связях контекстов, а решение в целом не сможет стать Large-scale structure. Конечно, это лично мои опасения, но возможно приписка [DDD-бичпакет] всё же нужна.
Поискав ещё немного, я понял почему конкретно вы для себя решили этот вопрос таким образом. И это вообще не отменяет элегантности предложенного решения. Уж простите мой догматизм, но риторика поста должна сохраняться.
Хорошего выступления завтра!
Соглашусь что у Вернона не всё хорошо, он действительно подходит слишком частно к решению. Каждый раз у меня сомнения что рекомендовать первой книгой по DDD. Однако, возможно проблема как раз в том что вы слишком буквально воспринимаете такие книги и статьи, не подходя критически, а принимая как руководство к действию? Со своим коллективом я долго проверял это как эксперимент, делая выводы, корректируя план.
Любая разработка не выгодна пока не принесла пользу бизнесу. Это инвестиция бизнеса.
Заметьте, B7W, что статья не совсем о божественности подхода, а о другом.
У Вернона подобласть — идеально выделенный экспертами предметной области ограниченный контекст.
Только если вы вырываете данные фразы таким образом из контекста, перевирая смысл.
встречный вопросы
Разве у нас не честный рынок?
Хотите берите такого человека, хотите увольняйте. А в следующий раз может люди к вам осознанно не пойдут, зная что вы сложных задач не решаете и тушите пожары.
А статья в принципе о том, что в угоду KPI менеджмента программистам приходится тесниться, занимаясь соглашательством и трансформируя практики, занимая выжидающую позицию, не редко в грёзах о полноценном проекте. И что хотелось сказать под конец — было бы не плохо поменьше менеджмента, разобщающих команды и решающего свои интересы.
Соглашусь полностью. При этом исхожу
Мне показалось, что автор интуитивно подводит к понятию предметно-ориентированного проектирования.
Разве лучший способ декомпозиции микросервисов не ограниченный контекст?