Comments 8
А у нас уже есть примеры написание одного фрейморка на базе другого фреймворка для использования в третьем или еще нет?
Хорошая архитектура программного обеспечения позволяет откладывать решения о Фреймворках, базах данных, веб-серверах и других вопросах, и инструментах, связанных с окружающей средой.
Как архитектура дома рассчитывается с учетом того, из чего этот дом будет построен так и проект делается с расчетом того что он будет использовать. Иначе это не архитектура проекта, а какая-то общая идея вида "Можно грабить корованы". Но от этой идеи не то что до готовой реализации, а до проекта ой как далеко.
Тоже хотел отметить, что архитектура сильно завязана на то, какие инструменты и материалы можно использовать. К примеру, имея только песок и воду вряд ли можно реализовать 3х этажный коттедж, нужен еще сам строитель и придумать, как сделать чтобы песок с помощью воды превратился в достаточно крепкий материал и приобретал нужную для использования форму.
Т.е. архитектура учитывает не только инструменты, но и параметры реализуемого объекта.
Бред. С какого это архитектура должна учитывать из чего будет все построено? Архитектура будет диктовать какие материалы и инструменты использовать. Может быть исключение, когда есть материал и нужна архитектура. Но это исключение. Архитектор ещё и предложит несколько вариантов по материалам. Как в строительстве, так и разработке.
Есть в Scala не популярный фреймворк Lagom для микросервисов, который в свою очередь построен на баз фреймворка Play, а он базируется на фреймворка Akka. ?
При проектировании кода, в котором задействованы возможности фреймворка, приходится идти на уступки из-за т.н. инверсии управления (к слову, наличие которой является ключевым отличием библиотек от фреймворков). Поэтому та часть проекта, в которой используется фреймворк, с огромной вероятностью, будет использовать архитектуру, навязанную фреймворком. Собственно, если проект целиком и полностью состоит из системы, контролируемой фреймворком, то, что "прокричит" ваш фреймворк, такая архитектура и будет.
Сложилось впечатление, что Автор призывает использовать сервисную модель.
Вообще, идея очень похожа на идеи, встречающиеся в функциональном программировании. В ООП я в чистом виде подобного не видел. Создается DSL для предметной области отвязанный от исполнения, а потом создается слой который исполняет этот DSL, соотвественно можно подменить среду исполнения (БД, фреймворки).
В итоге код может разделиться на две части модельные сущности и их взаимодействие описанной в терминах DSL, и слой исполнения этого DSL. Но вопрос цены такой разработки, как много специалистов готовы так делать и есть ли от этого существенные преимущества от такого подхода.
Конечно, можно так писать и в ООП, описывает логику и потом слой который свяжет нашу модель и фреймворк. Но опять же, какая будет цена такой разработки и какие преимущества даст такой подход. Все таки превращение Web приложения в консольное хотя и имеет место быть, точнее не превращение, а проявление дополнительного клиента, но всё же вещь редкая. Замена БД встречается, пожалуй, чаще, но все же достаточно редко и если происходит, то в этот момент, скорей всего, надо переосмыслить всю архитектуру так как поменялись требования.
Можно до какой-то степени достраивать дом, добавлять новые комнаты и даже этаж или два, но группы небольших мастерских превратить в большой мощный завод на фундаменте мастерских - не получится, фундамент надо будет менять.
это не архитектура, это структурирование кода. На эту тему уже довольно много и статей, и докладов
Кричащая архитектура