кококо

YAGNI & рефакторинг? Видимо, не слышал.

ОК, то есть если я понимаю правильно, можно в принципе отделить Change Management от технической доставки изменений и работать с высокоуровневыми требованиями по утяжеленному процессу.

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

ёкодзун

с гибкой разработкой, в частности частым и малым диплоям.

Много магии, мало пользы. Чуть в сторону от простейшего круда и нужно хорошо знать Хибернейт в дополнение к базе, что делает его пользу сомнительной.

Теперь на собесах еще и про отношение к прямому доступу к полям можно спрашивать. «геттер бойлерплейт кококо прямой доступ кококо» == двери там.

действительно и в обратную сторону

Цікаво, але не дуже зрозуміло. Що таке «система» в даному випадку? Мої мікросервіси stateless, скажемо.

колекціі, до речі, буває зручно в геттері обернути в Collections.unmodifiableXXX щоб запобігти myDto.getDataList.add("sneaky-sneaky") по всьому коду

Контроллеры — веб что-ли? А что если не только веб? Веб конторллеры должны вебом заниматься, а не поддержкой инвариантов.

Хто так робить? Ви таке бачили? Я — не бачив.

Бачив. Інколи навіть має рацію, але immutable + builders все ж краще, IMHO

то скарказм был, я так понимаю

Что именно в Спринге релевантно? Вроде там уже не там много на сеттеры/геттеры заточено.

Хайбирнейт — да, хотя ИМХО как раз пример как делать уже не нужно.

Kotlin не пробовал? Может понравится. А то имьютаблы с колличеством полей больше двух-трех в чистой джаве начинают быстро утомлять, а ломбок таки зло.

оба [процесса] предполагают процедуру утверждения, которая может осуществляться как специально выделенной группой людей (CCB в PMBoK или CAB и ECAB в ITIL), так и отдельно взятым человеком (руководитель проектов или спонсор в PMBoK и менеджер изменений в ITIL).

интересно, как эта процедура утверждения в идеале работает с Continuous Delivery & Trunk Based Development?

А то пришлось как-то с CAB процессом столкнуться — совсем не ажильно как-то было. Перегибы на местах?

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

Практически 99.99% случаев (может кроме либ некоторых) — дикий карго культ со времен первых bean-editors, заэнфорсенный всякими нехорошими либами и привычкой.

Пользовал во многих проектах просто поля, проблем особых технически не было (включая долгосрочную поддержку). С людьми сложнее. Джуны скулили что в книгах по-другому написано; мидлы жаловались на привычку тыцнуть «.get» и ждать подсказки IDE.

Потом Котлин пришел на бек-энд и скрыл это безобразие из кода в байткод.

Переписувати часом потрібно, і коли хтось береться — то чом би й ні?

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

5. Может быть вполне нормальной переходной ситуацией когда вдруг с ростом объема данных выясняется, что база хоть и реляционная, но много джойнов — это тяжко. Впрочем, боль поддержки двух типов схем понятна, денормализацию нужно пользовать аккуратно.

Ну логично, что на самом магистральном и забитом маршруте будет непросто. Попробовать после 9и выезжать можно, и посвободнее и дешевле. Ну или работу менять. Или место жительства. Чудес не бывает, чтобы и все хорошо было и просто.

Ну тут уже надо смотреть детально по ситуации.

Рассмотрим развитую часть Голландии (Рандстад) вне центра больших городов.

Машина сама по себе нужна по 4 причинам (упрощенно):

— статусный символ / увлечение. Это не рассматриваю, так как не релевантно вопросу пробок и удобства владения.

— свободное время — проблем в основной Голландии нет. Топливо разве что дороговато, но не является предметом жалоб.

— детей развозить. Живя не в центре большого города проблемой быть не должно. Основные пробки на автомагистралях, на которые обычно в такой ситуации выезжать не нужно. Кроме того расстояние скорее всего будет доступно на велосипеде, что еще более упрощает в жизнь в хорошую погоду или с дождевиком при желании.

— коммют между домой и работой. Тут конечно все сильно зависит от многих факторов.

— пробки на автомагистралях сильно зависят от конкретного направления. Скажем, из Амстердама в Утрехт добираться может быть проще, чем из Роттердама. Сильно зависит от конкретного заезда и съезда. Рыбные для работы места значительно менее сосредоточены географически чем в Киеве. Много достаточно интересных вариантов в этих городках поменьше или вне центра больших городов.

— пробки сильно зависят от времени суток. Если есть возможность сдвинуть график (начинать работу в 7, заканчивать в 4 или наоборот позже), то даже самое пробочное направление может быть вполне терпимым. Обычная стратегия местных автокоммютеров из моего круга общения.

— парковочная ситуация сильно варьирует. Может полностью предоставляться или компенсироваться работодателем, особенно если расположение не в самом забитом центре. Если в центре, то система P+R вполне работоспособна, где можно оставить машину по человеческому тарифу и добраться дальше общественным транспортом, который обычно хорошо связывает точки P+R с центрами деловой активности.

— опять же вполне возможно, что общественным транспортом будет удобно добираться. От места моего проживания до центра Амстердама добраться проще и быстрее, чем от некоторых частей того же самого амстердамского Осдорпа.

— — плюс в общественном транспорте типа «поезд» нашему брату АйТишнику обычно можно вполне комфортно работать, совмещая коммют с рабочим временем, хотя могут быть сегменты сильно загруженные в час пик в зависимости от направления.

1. Начал я с прилета в Амстердам, арендовал апартаменты в Osdorp.

Амстердам — место на любителя, те же Голландцы часто переезжают из него с появлением детей

— общественный транспорт сильно получше Торонто, хоть и дорогой, но все равно не вариант

чем не вариант?

— субъективно ужасная погода — дожди, ветра, отсутствие нормального лета

Лето нормальное. Дожди бывают, но не сказал бы чтобы принципиальное отличие от того же Киева субъективно. Ветра — да, есть такое, смог зато не задерживается :)

— в центре неприятно находится из-за толп и запаха травы

Логично. Не нравится такая тусня — прочь из центра.

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

В больших городах привыкаешь через пару месяцев. В меньших населенных пунктах цивильнее.

— дорогое содержание авто, неудобно ездить/парковаться

Не надо зацикливаться на центре Амстердама. Вне больших городов автомобильное движение вполне себе развито и доступно.

— 70к как будто потолок

Субъективно — нет. Но если чисто бабла срубить, то Европа в целом не очень. Разве что контрактером.

— очень дорогие детские садики 

Шо есть, то есть. Еще и с очередями.

— «парацетамольная» медицина

Есть такое. Само по себе не плохо, но желателен хороший семейный врач (huisarts) и отсутствие привычки лечиться для лечения.

Лучше разбей предметную область пологичнее для синтетического проекта. Например, данные о клиентах в одном сервисе, кредиты / дебеты с балансами в другом. И чтобы не совсем тривиально было — данные клиентов могут меняться, но должны быть неизменны для определенных транзакций (вчерашняя выписка если я сегодня поменял адрес). Ну и GDPR прикрутить.

Неплохо бы определиться что хочешь отработать в упражнении. Микросервисы решают определенные проблемы ценой увеличивая других. Масштабируемость в разработке растущей командой/командами, более явные интерфейсы взаимодействия между компонентами и повышенная изолированность оных достигается ценой усложнения инфраструктуры. Так что вполне возможно, что базу в реальной ситуации таки будет сложнее обслуживать.

Дублирование данных в микросервисах — это в целом нормально. База может быть одна физически, но с жетским разделением схем.