Size: a a a

Архитектура ИТ-решений

2020 August 13

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Andreλ
Если в вакансии пишут в списке аббревиатур DDD, то обычно это означает не полное следование всем возможным спеккам DDD. Все проекты с такой лычкой, что я видел, были "по мотивам DDD". Люди брали понятные части и применяли в проекте. Например Bouтded Context. Или строили сущности не как обычно в ООП принято. Но никто обычно не заморачивается с полным построением по DDD, со всеми наворотами.
Даже использование только лишь стратегических паттернов DDD полезно
источник

AN

Andrew Nilove 💔 in Архитектура ИТ-решений
Alex
я бы сказал, что часто DDD в списке означает, что будет свалка паттернов, в которой без поллитры не разберешься, и лучше бы эти люди про DDD не знали вообще.
однако в этих конторах
1) эти люди громче всех кричат
2) больше всех получают

умение продавать это нужный навык
источник

A

Alex in Архитектура ИТ-решений
Gennadiy Kruglov
Даже использование только лишь стратегических паттернов DDD полезно
но обычно наоборот берут только тактические, они ж понятней
источник

VU

Vitaly U in Архитектура ИТ-решений
Andrew Nilove 💔
"А за дизайн не платят, платят за кодирование. "
Вот с этим люто согласен. Печально наблюдать, что бизнес в лучшем случае владеет правилами арифметики, на то, что у него творится в системах, ему глубоко все равно с высокой колокольни. Однако, когда нырнешь внутрь кода этих систем, то хочется убивать.
Суть не в плохом качестве кода, для бизнеса это вполне материальные затраты на вывод каждой фичи, тяжело сопровождать, тяжело развивать, тяжело == дорого
источник

VU

Vitaly U in Архитектура ИТ-решений
Ну если это не бюджетное учреждение и там один Вася-программист и доставшееся легаси, тогда тяжело только Васе)
источник

AM

Andrei Moiseev in Архитектура ИТ-решений
Gennadiy Kruglov
Даже использование только лишь стратегических паттернов DDD полезно
Я бы сказал, что только использование стратегических паттернов и полезно)
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Alex
на одном из круглых столов мы пришли к такому критерию: если заказчик смотрит в код и понимает бизнес-логику, то значит этот код соответствует подходу DDD. Если нет - то нет. То что на схеме может как соответствовать DDD, так и нет. Все зависит от того, что именно у написано внутри services и в прочих местах. Сама картинка не про DDD.
Хорошее определение
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Andrei Moiseev
Я бы сказал, что только использование стратегических паттернов и полезно)
Я не настолько смел, чтобы делать подобные утверждения)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Alex
но обычно наоборот берут только тактические, они ж понятней
Да, ближе к коду
источник
2020 August 14

d

dn.khelilov in Архитектура ИТ-решений
Коллеги! Подскажите, пожалуйста, я хотел бы следить за изменение структуры БД в гите, и наверняка я не первый такой. Кто как решает эту проблему?
источник

HC

Henry Chinaski in Архитектура ИТ-решений
flyway migration
источник

RP

Rifat Pozdnyakov in Архитектура ИТ-решений
источник

NL

Nikolay Loginov in Архитектура ИТ-решений
liquibase, кстати недавно открыл портал по обучению https://learn.liquibase.com/ сейчас есть курс бесплатный Liquibase Fundamentals
источник

d

dn.khelilov in Архитектура ИТ-решений
Спасибо, посмотрю!
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Заметил, что сейчас модно дружить.

Когда озвучивают вакансии, говорят, нужно с тем-то подружиться и с тем-то, со всеми подружиться.

Для меня это означает - у нас тут **па, но мы вам полномочия не дадим.

Крылов про такую дружбу в своих баснях уже написал всё, что нужно.

Если кто-то открыто саботируют процесс, не компетентен, не готов принимать изменения, то не надо с ним дружить, не надо его убеждать, не надо учить, нужно орг выводы делать.
источник

П

ПашМиш in Архитектура ИТ-решений
Gennadiy Kruglov
Заметил, что сейчас модно дружить.

Когда озвучивают вакансии, говорят, нужно с тем-то подружиться и с тем-то, со всеми подружиться.

Для меня это означает - у нас тут **па, но мы вам полномочия не дадим.

Крылов про такую дружбу в своих баснях уже написал всё, что нужно.

Если кто-то открыто саботируют процесс, не компетентен, не готов принимать изменения, то не надо с ним дружить, не надо его убеждать, не надо учить, нужно орг выводы делать.
Может быть дело в том, что у нас не очень все круто с soft skills? HR видит конфликты в коллективе и пытается выправить ситуацию как умеет.
источник

HC

Henry Chinaski in Архитектура ИТ-решений
Gennadiy Kruglov
Заметил, что сейчас модно дружить.

Когда озвучивают вакансии, говорят, нужно с тем-то подружиться и с тем-то, со всеми подружиться.

Для меня это означает - у нас тут **па, но мы вам полномочия не дадим.

Крылов про такую дружбу в своих баснях уже написал всё, что нужно.

Если кто-то открыто саботируют процесс, не компетентен, не готов принимать изменения, то не надо с ним дружить, не надо его убеждать, не надо учить, нужно орг выводы делать.
эх, вашими бы устами мёд пить
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
ПашМиш
Может быть дело в том, что у нас не очень все круто с soft skills? HR видит конфликты в коллективе и пытается выправить ситуацию как умеет.
Попробую сузить контекст. Я хотел сказать, что когда проводятся изменения, всегда находятся люди, которые их не ждут. Они изначально враждебно настроены по отношению к проводникам изменений. Тут конфликтов (интересов) не избежать.

Овца не сможет обратить в свою веру волка, сделать его травоядным. Вместо овцы нужен ещё более сильный волк.
источник

П

ПашМиш in Архитектура ИТ-решений
Gennadiy Kruglov
Попробую сузить контекст. Я хотел сказать, что когда проводятся изменения, всегда находятся люди, которые их не ждут. Они изначально враждебно настроены по отношению к проводникам изменений. Тут конфликтов (интересов) не избежать.

Овца не сможет обратить в свою веру волка, сделать его травоядным. Вместо овцы нужен ещё более сильный волк.
Да, это почти аксиома, всегда есть те, кому изменения не выгодны. А отсутствие soft skills тут очень хорошо превращает взрывоопасную ситуацию в пожар.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Gennadiy Kruglov
Попробую сузить контекст. Я хотел сказать, что когда проводятся изменения, всегда находятся люди, которые их не ждут. Они изначально враждебно настроены по отношению к проводникам изменений. Тут конфликтов (интересов) не избежать.

Овца не сможет обратить в свою веру волка, сделать его травоядным. Вместо овцы нужен ещё более сильный волк.
Я тут помню один принцип из дворового дества. Если его перевести на цензурный, то он звучит как:
"Всех побить, остальным по лицу".
источник