При проектировании системы лучше всего ориентироваться на дизайн, который вы будете использовать?

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

Ваш дизайн должен максимально соответствовать потребностям клиентов. Помните, что дизайн включает в себя такие мелочи, как:

• Пользовательский опыт
• функциональность
• Как части вашего приложения взаимодействуют (либо с самими собой, либо с внешними объектами)

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

После того, как вы выбрали подходящий набор инструментов (фреймворк - это инструмент), я рекомендую использовать инструменты так, как они предназначены для использования. Чем дальше вы отклоняетесь от структуры фреймворка, тем больше вы увеличиваете кривую обучения для своей команды и тем больше вероятность, что что-то пойдет не так.

Короче

• Дизайн для ваших пользователей
• Выберите подходящие инструменты для реализации вашего дизайна
• Используйте ваши инструменты так, как они предназначены для использования

Дальнейшие мысли:

За 20 с лишним лет разработки программного обеспечения и использования нескольких фреймворков я усвоил пару уроков. Все рамки являются обоюдоострым мечом: они оба ограничивают и поддерживают. Проблема с выбором вашей платформы, прежде чем вы посмотрите на большую тройку, которую я упомянул выше, заключается в том, что вы можете поставить под угрозу хороший пользовательский опыт для посредственной (в лучшем случае). Или вы можете быть вынуждены отклониться от дизайна фреймворков, чтобы выполнить некоторые специфические функции.

Фреймворки естественным образом влияют на дизайн определенных модулей и подсистем (таких как интерфейс GUI). Как уже упоминалось в другом ответе, вам будет трудно, если вы столкнетесь с выбранными вами рамками.

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

Скорее всего, вы будете использовать много разных фреймворков для решения разных проблем; по мере того как ваша система становится все более сложной, вы должны быть осторожны, чтобы не создавать «Большой шарик грязи» . Где возможно, держите вашу систему модульной и слабо связанной. Некоторые фреймворки лучше оставить за абстракциями, написав оболочки и адаптеры, которые «скрывают» специфичные для фреймворка рабочие процессы от других компонентов. Инструментарий GUI, как правило, обслуживает только интерфейсные функциональные возможности GUI, поэтому эти модули GUI следует хранить отдельно от остальной системы.

Каркасы общего назначения (такие как каркасы пользовательского интерфейса, каркасы уровня данных и т. Д.) Не существуют, чтобы предписывать полную архитектуру вашей системы - в большинстве случаев они могут предписывать разработку компонента или модуля; например, некоторые технологии GUI ориентированы на определенные шаблоны MV *.

Общая архитектура вашей системы должна в первую очередь зависеть от требований вашего бизнеса . Может оказаться, что вы сильно полагаетесь на конкретный инструмент (например, инструмент межплатформенного обмена сообщениями или среду ORM), чтобы связать все воедино, но если вы инкапсулировали среду в абстракцию, такую ​​как класс «сервис», вы менее вероятно, что вы столкнетесь с этой системой, когда столкнетесь с ее ограничениями.

Постарайтесь учесть следующее:

• Цель создания модульного программного обеспечения
• Учитывайте разделение проблем при написании каждого модуля и компонента
• Рассмотрим многоуровневую архитектуру для разделения системы на слои
• Не создавайте Leaky Abstractions
• Сокращения по этому смежному вопросу : как классифицируются как СУХОЙ, ПОЦЕЛУЙ, ТВЕРДЫЙ и т. Д.?

Да, вы должны как можно точнее придерживаться того, что фреймворк «говорит» вам делать.

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

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

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

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