Принятие решений об архитектуре вашего проекта; каков ваш процесс принятия решений?



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



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



Каковы некоторые из факторы, которые вы учитываете при проектировании архитектуры для нового проекта? Есть ли у вас последовательный дизайн проекта, который вы часто используете, являетесь ли вы n-уровневым с самого начала, или вы оцениваете по мере поступления каждого проекта?



Имея этот опыт неоднократно, я часто задаюсь вопросом, как другие в том же положении оправдывают и делают эти соображения. Я уверен, что у всех нас будут разные мнения, но я верю, что понимание мыслительного процесса, стоящего за этими мнениями, будет поучительным.
484   7  

7 ответов:

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

Правка:

Для "типичных" бизнес-решений вот некоторые из факторов, которые я рассматриваю:

  • UI

    • может ли он быть основан на интернете? Каковы требования к взаимодействию с пользователем?
    • Если классического веб-интерфейса недостаточно, можно ли использовать более интерактивную технологию, такую как Sliverlight?
    • Если это должен быть толстый клиент (да, есть еще сценарии, которые оправдывают это), насколько серьезны проблемы развертывания? Маленькая база пользователей, большая база пользователей? Нужно ли включать автоматическое обновление? Нужно ли его применять?
  • Бизнес-Уровень

    • есть ли у меня соображения производительности/масштабируемости, которые требуют физически отдельного деловой слой? (Мои бизнес-уровни всегда логически разделены, и при необходимости их легко разделить физически. Я иногда использую CSLA , чтобы учесть это решение во время развертывания при таргетинге на Windows, но это тяжелый фреймворк и не всегда подходит).
    • , как простые, так и сложные-мои правила бизнеса? Могут ли они значительно эволюционировать с течением времени? Стоит ли включать механизм правил, такой какDrools ?
    • есть ли асинхронная обработка требования? Нужна ли мне система рабочих очередей?
    • Существуют ли внешние системы для взаимодействия с ними? Какие типы интерфейсов они представляют? Web service, COM+, XML over HTTP, proprietary, DB, batch files, ...?
  • Сохранение Данных

    • какие варианты ORM доступны мне с учетом любых ранее существовавших вариантов/ограничений платформы?
    • выиграю ли я от широкого использования хранимых процедур? Будет ли DBA для поддержки хранимых процедур и изменять их со временем? Если нет DBA, я использую хранимые процедуры только там, где это действительно необходимо для производительности. При наличии DBA более широкое использование хранимых процедур дает DBA гибкость в управлении физической архитектурой независимо от приложения (но, как и при всей дополнительной сложности, это сопряжено с затратами).
  • Сквозное

    • каковы требования к безопасности? Существует ли существующий механизм (Active Directory / LDAP/...) быть интегрированным с? Нужно ли поддерживать безопасность на основе ролей?
    • каковы требования к оперативному мониторингу? Функциональность "сообщить об этой ошибке"? Простое ведение журнала?
  • Хорошо, позвольте мне быть тем, кто скажет вам-просто сделайте это. Сконцентрируйтесь на любых требованиях, которые у вас есть сейчас, но не пытайтесь рассмотреть все возможные будущие особенности, воображаемые изменения требований и различные направления развития.

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

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

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

    Следуйте принципу поцелуя и избегайте преждевременной оптимизации.

    Есть ли у вас последовательный дизайн проекта вы часто используете?

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

    Вы с самого начала n-й уровень?

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

    Или вы оцениваете как каждый проект входит

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

    Где вы, или хотели бы вы, провести черту на пути к "следующему шагу" в создании архитектурно здоровой и масштабируемой системы?

    Я не понимаю этой части вопроса.

    Какие факторы вы учитываете при проектировании архитектуры нового проекта? Есть ли у вас последовательный дизайн проекта, который вы часто используете, являетесь ли вы n-уровневым с самого начала, или вы оцениваете по мере поступления каждого проекта?

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

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

    Рассмотренные факторы:

    1. Думает ли команда, что архитектура выполнит свою работу? Превосходит все остальные соображения.

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

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

    4. Есть ли части, которых мы не понимаем, или, что еще хуже, есть части, которых мы боимся? Если это так, то главные красные флаги.

    5. Разве это красиво? Это то, о чем мы с гордостью будем говорить за обедом с другими командами? Если нет, то дизайн/архитектура, вероятно, еще недостаточно хороши.

    6. Есть ли идентифицируемая новая идея? Что-то, чему другие могут научиться? (Это важно в исследовательской среде, но я подозреваю, что не важно в другом месте.)

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

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

    1. собраться Требования
    2. приоритетность требований (не тратьте много времени на функции золотого покрытия)
    3. обычно я начинаю с 2-го уровня (UI / Data&Business logic), если не знаю, что уровни Data & Business logic будут разделены спереди.
    4. для каждого требования сначала заставьте его работать. Здесь нет никаких закономерностей, если только не очевидно, что это необходимо. Я нахожу, что потребность в паттернах возникает в процессе реализации.
    5. после того, как он заработает, очистите код, определите места для шаблоны и реализуйте их только в том случае, если вам нужно
    6. если производительность является требованием, выполните тестирование производительности, рефакторинг по мере необходимости.
    Если вы будете работать таким образом, то обнаружите, что ошибаетесь в сторону простоты. Шаблоны, сторонние инструменты и т. д. могут быть совершенно потрясающими при решении конкретных проблем, но я хотел бы иметь в виду, что каждый раз, когда я добавляю что-то подобное, это поднимает планку понимания, необходимую для поддержания приложения позже. Так что я начинаю просто, и добавить сложности только тогда, когда это специально приносит мне что-то.

    Я на самом деле получаю довольно неприятный привкус во рту, когда имею дело с другими архитекторами, которые даже для небольшого, простого приложения потянутся к фреймворку инъекции зависимостей, Nhibernate, NUnit, катят свою собственную библиотеку журналов, пишут в 3 раза больше модульных тестов, чем строк кода, и т. д. Все эти инструменты имеют конкретные примеры, когда ROI (рентабельность инвестиций, "bang for your buck") очень хорош и другие хороший архитектор обеспечивает столько ценности, сколько он может при минимальных затратах времени и средств.

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

    Они также понимают разницу между логическим и физическим разделением уровней.

    Слишком часто я вижу один из двух паттернов:

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

    (если единственные проблемы архитектуры, которые вам нужно решить, - это сколько уровней должно быть в вашем решении, то вам действительно повезло : -)

    Я использую пружину - все это встроено.

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

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

    Comments

      Ничего не найдено.