Все его построения заменяются банальной трёхзвенкой, и если что будет заменено в будущем, то просто эта часть переписывается.

Не следует всё радикализировать. Каждый случай имеет аргументы за и против. А смотреть на всё исключительно со своей колокольни не есть оптимальный вариант.

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

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

Но вот понадобилось "отвязать" одну часть...

Пример моего проекта. Изначально был написан какими-то надмозгами - полстапроектов в солюшене. Куча слёв. Всё модульное, динамичное, расширяемое шопипец. Те, кто писали проект, продали его крупной фирме и удалились. Эта крупная фирма сама поддерживала проект лишь в части написания бизнес-логики, а вся остальная кухня эксплуатировалась почти без изменений примерно 15-20 лет, пока не прекратилась поддержка платформы, на которой крутилось гуёвая часть. Никакими расширениями никто не воспользовался. Вместо этого забронзовевший код не позволял использовать современные сторонние решения, т.к. никто не знал, как заменить скажем свою самописную ORM на нормальную современную, чтобы ничего не сломалось. Надмозги несколько лет писали спагетти-архитектуру, которая во многом оказалась не нужна. И трудноподдерживаема, если ты сам не тот надмозг, который её создавал.

В результате сильно позже и другие разработчики стали в авральном темпе переписывать всё на новое, удивляясь применяемым 20 лет назад решениям. Но тоже костыльным способом - сначала самые понятные и не сильно зависимые части, чтобы чего не сломать. Т.е. пишем новый гуй на современных технологиях, но с подходами старыми, создавая кучу подгоняющей обвязки - чтобы совместимость с другими слоями осталась. И пока сохраняем самописную ORM. Когда всё будет заменено, придётся эти подгоночные костыли убирать. Т.е. переписывать проект придётся в несколько проходов по одним и тем же слоям. Гораздо проще, понятнее и быстрее было бы постепенно обновлять все части приложения, переписывая их на современный манер и выкидывая самописные костыли и оказавшиеся ненужными переусложнённые вещи. А теперь придётся делать примерно то же самое, но не постепенно, а в авральном режеме.

Так что я вашу многослойность, модули и расширяемость труба шатал. За 15-20 лет устаревает сама архитектура и её подходы - все модули и слои скопом отправляются в помойку. Не к чему подключать, нечего расширять.

Да уж, накипело у вас... Я даже не поверил сначала, что вы всерьез все это пишете.

Понапридумывают этих ваших архитектур, а людям мучаться. Действительно, проще же все переписать:)

Так он прав.

Так что я вашу многослойность, модули и расширяемость...

Так о чём я и говорю, не надо всё радикализировать и обобщать. То что вам попался вариант неудачной архитектуры не означает, что везде всё так плохо с архитектурой. А вот то, что любой проект за 15-20 лет можно изменить до неузнаваемости в худшую сторону - это весьма и весьма вероятно. По крайней мере, обратного еще не попадалось.

Гораздо проще, понятнее и быстрее было бы постепенно обновлять все части приложения, переписывая их на современный манер

Опять голубые мечты... сами же написали: "сначала самые понятные и не сильно зависимые части, чтобы чего не сломать."

А что делать с непонятными и сильно зависимыми частями?

Мне непонятно, как структурированный код можно называть спагетти? Это что ошибка в терминологии? Мне непонятно стремление к переписыванию всего и вся (весь мир пытается использовать код повторно и экономить деньги). Мне не импонирует агрессивное невежество. Проекты не живут в вакууме, и тимлид, которого тут так уничижительно поминали, должен учитывать всевозможные аспекты проекта. Даже те, которые не видны с низкого горизонта джуниоров и просто не могут быть ими осознаны, в силу отсутствия опыта. Наличие множества слоев (Layered Architecture), как раз признак, того что тимлид прекрасно отдает себе отчет, что такое менеджмент изменений и как можно редуцировать риски и затраты на поддержку. Это как раз называется зрелость, один из критериев качества продукта по ISO 25010, кстати.

Тут много еще чего можно написать, но мне просто лень.:)

То что вам попался вариант неудачной архитектуры

Я думаю, что архитектура соответствовала своему времени и вполне отвечала требованиям. Потом ее бросили (ушел архитектор) и она стала дрифтовать, накапливался technische Schuld и т.д. Потом технологическая платформа устарела и всех бросили на "починку". Обычная история:)

Кстати удачность или неудачность оценивается в процессе ревью и другим архитектором. А не так как тут, поплевали на руки и оценили на раз:)

Я думаю, что архитектура соответствовала своему времени и вполне отвечала требованиям

Бессмысленно обсуждать событие основываясь на показаниях одного не очень объективного свидетеля.

Можно гадать долго и нудно.

Но, судя по тому, что есть слабо связанные и сильно связанные части я бы ставил на красное вариант неудачной архитектуры.

архитектура соответствовала своему времени

просто ради интереса и язык немного почесать

А насколько устарел труд Эрика Эванса? Или хотя бы "Алгоритмы и структуры данных" Вирта от 1984 года?

В мусор и не вспоминать?

просто ради интереса и язык немного почесать

Конечно, а как же иначе. Не на серьезных щах же все обсуждать:)

Не на серьезных

Можете подойти и по серьёзному, если так нравится.

Мне непонятно, как структурированный код можно называть спагетти? Это что ошибка в терминологии? Мне непонятно стремление к переписыванию всего и вся (весь мир пытается использовать код повторно и экономить деньги). Мне не импонирует агрессивное невежество. Проекты не живут в вакууме, и тимлид, которого тут так уничижительно поминали, должен учитывать всевозможные аспекты проекта. Даже те, которые не видны с низкого горизонта джуниоров и просто не могут быть ими осознаны, в силу отсутствия опыта. Наличие множества слоев (Layered Architecture), как раз признак, того что тимлид прекрасно отдает себе отчет, что такое менеджмент изменений и как можно редуцировать риски и затраты на поддержку. Это как раз называется зрелость, один из критериев качества продукта по ISO 25010, кстати.

Тут много еще чего можно написать, но мне просто лень.:)

Если бы вы знали юзера alex445 получше, то не задавались такими вопросами, его здесь на форуме пинают все кому не лень!

Он то университеты "Лиги плюща" - наперсточниками обзовёт, то Маска и криптомиллиардеров со своими фекалиями сравнивает.

Но достаточно посмотреть на какой стыдной машине он ездит и всё ясно и понятно, при этом очерняет Теслу и другие электрокары!

Даже на автора библии сишарпников, на Джон Скита поплеваться успел... что слишком много книжек пишет! За ответ на стековерфлоу.

Вопросы и Ответы - Программируем калькулятор пособий для беженцев вместе.

Да уж, накипело у вас... Я даже не поверил сначала, что вы всерьез все это пишете.
Понапридумывают этих ваших архитектур, а людям мучаться. Действительно, проще же все переписать:)

Архитектуры работают там, где их используют правильно и со знанием дела, регулярно подновляют, заменяют в них старые технологии новыми. Т.е. когда у приложения есть хозяин, который за ним постоянно следит. Обычно это продукт, поддерживаемый одной командой без радикальной смены хозяев, на протяжении долгого времени. Т.е. это очень малое количество случаев. Во всех остальных случях сложные навороченные архитектуры, написанные по всем канонам разных "чистых кодов" и прочих "библий" программирования, в основном не работают и даже вредят, усложняют и тормозят процесс. В "библиях" об этом забывают упомянуть, рассказать неофитам правду жизни. "Ребята, вы прочитали "что такое хорошо, и что такое плохо" из мира программирования? А теперь забудьте - в большинстве случаев в вашей жизни это применяться и работать не будет." Поэтому переписать - зачастую самое правильное решение. Особенно при смене владельца, команды. Оно, вобщем-то, и используется. А все прежние старания и навороты идут прахом, какими бы гениальным и правильными они ни были.

То что вам попался вариант неудачной архитектуры не означает, что везде всё так плохо с архитектурой.

Архитектура-то как раз отличная была. Для своего времени. Я же говорю, писали надмозги. В хорошем смысле слова. Хоть и полста проектов в солюшене, но само приложение было далеко не монолит, а как сегодня модно - куча разных сервисов, работающих на разных серверах и общающихся между собой. Были сервисы, создающие динамические типы данных на лету из конфигурационных файлов, послылающие потом их на сервер приложений и создающие там эти типы активаторами. Свой сериализуемый язык запросов и самописная ORM, которые в то время (начало 2000-х) только начали пробивать себе дорогу. Свой гуёвый фреймворк, хоть и основанный на контролах ASP.NET, но сильно их расширяющий. Своё управление состоянием, когда то, что на вебсайте понавводили в формы, можно сохранить в сессию, затем в базу данных, и потом загрузить снова. И на всё это - пачка разных клиентских приложений - от веб-сайтов, до десктопа и PDA. Но времена изменились, и "гениальные" раньше подходы теперь выглядят костылями. Я поначалу тоже думал, глядя на это - кто эту хрень понаписал, зачем, люди себе работу придумывали? Потом посмотрел на технологии, почитал про них в Википедии, на года, когда они были придуманы и применялись. - Да, в своё время это выглядело революционно, на острие прогресса. А сейчас - лютая дичь, которую нужно просто выкинуть в помойку. И не поможет ей никакая архитектура, модульность, расширяемость и интерфейсы по все поля.

Мне непонятно, как структурированный код можно называть спагетти?

Есть спагетти-код, а есть спагетти-архитектура. На каждом уровне можно намутить своё спагетти.

А насколько устарел труд Эрика Эванса? Или хотя бы "Алгоритмы и структуры данных" Вирта от 1984 года?


В мусор и не вспоминать?

Общие рекомендации вида "делай хорошо и не делай плохо" конечно не устаревают. Устаревают конкретные реализации этих рекомендаций. "Гладко было на бумаге..."

Архитектура-то как раз отличная была. Для своего времени... Потом посмотрел на технологии

Мне кажется, мы говорим о немного разных вещах.

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

И если вначале был набор со слабо связанными модулями, то таким он и должен быть остаться. Поэтому варианта как минимум два: или вначале всё было не так хорошо, либо в процессе модификаций произошли серьезные изменения.

Мне часто встречается именно комбинация и первого и второго.

Устаревают конкретные реализации этих рекомендаций.

Ну давайте возьмем, что-то хорошо написанное, но старое.

Вот сколько раз "Никсы" с нуля переписывались заново за последние 20 лет?

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

Задача - сделать из такой кареты современный автомобиль. Благодаря модульности, можно заменять всё по частям, и всё будет продолжать работать. Но лучше просто сделать автомобиль с нуля, а карету на помойку или в музей.

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

Задача - сделать из такой кареты современный автомобиль

Ну так это устаревшие технологии. Сам то принцип построения остается без изменений.

что в моём случае карета таки должна продолжать работать, а автомобиль из неё будут лепить, заменяя модули. При этом буквально по ходу движения кареты.

Какие есть более лучшие предложения с точки зрения бизнеса?

Ничего не напоминает?

Прикреплённые файлы

Единственный минус видится (ещё не пробовал) - передать такой тип данных куда-то - надо указывать всю портянку кортежа - типа
MyMethod((int, string, bool) methodParameter);

Открой для себя интерфейсы :)

Кортежи - это хреновила исключительно для локального использования.