Как определить абстракцию и область для архитектуры и дизайна соответственно?

Question

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

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

Существуют ли какие-либо способы / методологии / подходы, которые можно использовать, чтобы ограничить себя в границах архитектуры, покая обращаюсь к нему, а также к дизайну, когда я нахожусь на этапе проектирования?

Answer 1

Сделайте шаг назад - вы находитесь на этапе архитектуры, так какие же результаты должны быть получены на этом этапе? Знаете ли вы, кто является заинтересованными сторонами в вашем проекте, которые вы должны предоставить? - что им нужно / ожидать? Суть, которую я хочу подчеркнуть, заключается в том, что если вы не четко определили, что именно вам нужно сделать - это не будет сделано (независимо от того, какой метод вы используете).

Ограничения / Сохранение цели

Хорошая архитектура пройдет 3 уровня, и это хорошая основа для подхода:

• Направление высокого уровня: делайте все возможное, чтобы проверить (и быть в состоянии оправдать) данное направление. Какую систему мы строим? Настольная система, которая используется персоналом в офисе или система, которая может использоваться удаленными пользователями в любой точке страны?
• Логические варианты: держитесь подальше от деталей реализации, вместо этого сосредоточьтесь на определении основных компонентов, которые вам понадобятся. Нам нужно хранить данные, нам нужно аутентифицировать пользователей по этой существующей внешней службе, нам нужно предоставить пользовательский интерфейс.
• Физические возможности: здесь вы попадаете в детали написания того, что будет использоваться. Чтобы вернуться к метафоре ИТ: используем ли мы структуру сопоставления сущностей, развертываем собственную или повторно используем встроенную собственную?

Для всего этого вы должны быть в состоянии найти эталонные архитектуры или «предшествующий уровень техники», который поддерживает ваш подход.

Входные данные в эти 3 шага могут быть значительными и должны включать:

• Контекст (все, что касается среды, в которой должно работать решение): размер населения, распределение, техническая зрелость (как пользователей, так и персонала, который будет его поддерживать), чувствительность данных, характер бизнеса и как система связана с этим - обрабатывает ли система медицинские записи в реальном времени (вопрос жизни и смерти) или это вики?
• Нефункциональные требования (а): Определите 3 лучших в порядке приоритета, поскольку это будет ключевым руководством для принятия архитектурных решений. Является ли производительность наиболее важной? Или безопасность? Доступность? Это будет зависеть от контекста.
• Нефункциональные требования (b): они также будут зависеть от контекста, но они также предоставляют (надеюсь, проверяемые) метки, которые вам нужно получить: насколько быстро, насколько доступно, как можно использовать, как оно обрабатывает DR.

Выходы , которые вы должны быть в состоянии предоставить (подумайте о том, как вы можете это сделать), включают:

• Какое-то определение архитектуры решения. обычно это официальный документ, но может и не понадобиться. Он должен включать информацию, касающуюся «представлений», относящихся к решению / проблеме / контексту: логическое представление компонентов системы, включая внешние интерфейсы и системы, с которыми вы взаимодействуете, физическое представление о том, где будут развернуты компоненты системы, если вы При написании программного обеспечения вам также нужно будет описать, как это программное обеспечение разделено на физические пакеты, которые можно развернуть, безопасность, данные и т. д.
• Реестр решений: это будет живой регистр, который вы добавляете на протяжении всей жизни проекта. Используйте его, чтобы объяснить, почему были приняты определенные решения. Это защищает вас, если вам в любой момент угрожают, и поможет вам / другим через 6 месяцев, когда возникнет проблема, и вам нужно вспомнить почему вы сделали то, что сделали.

Детали и дизайн

Проектирование - это то, где вы попадаете в подробные детали, это может включать шаблоны, которые будут использоваться на уровне объекта, и так далее. Это время и место, где вы можете предоставить эталонные реализации: так мы должны структурировать наши сервисы и т. Д.

Answer 2

Боюсь, что единственный реальный ответ - это практика;практика;практика.Однако я обнаружил, что при рассмотрении вопроса о распределении тем между различными областями полезно постоянно напоминать себе о трех вещах.

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

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

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

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

РЕДАКТИРОВАТЬ:

Что касается инструментов, я нашел инструменты, которые помогут придумать большую часть помощи.Программное обеспечение Mind Mapping, такое как Mind Manager ;Инструменты UML, такие как вы упоминаете;инструменты типа доски, где предметы можно размещать, перемещать и дополнять с помощью того же средства, что и доска;и (если в корпоративной среде) программное обеспечение для проведения мозгового штурма.Я не могу дать ссылки на эти последние инструменты, потому что мои знания сильно устарели.Также может помочь помещение всех ваших заметок под контроль версий, разделенных по задачам в разные проекты.

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