Короткая история: Что должен делать архитектор?

Эта статья — короткий рассказ, имитирующий Q&A, и автор использует юмористический стиль, чтобы кратко проанализировать работу архитекторов: Я хочу быть архитектором программного обеспечения.

Это отличный вариант для молодых разработчиков программного обеспечения.

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

О, тогда тебе вообще не стоит быть архитектором программного обеспечения.

Конечно, я хотел принимать важные решения.

Это нормально, но вы не включаете важные решения в свой список, которые не имеют значения.

Что ты имеешь в виду? Вы хотите сказать, что базы данных — не важные решения, знаете ли вы, сколько мы на них тратим?

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

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

База данных — это всего лишь устройство ввода-вывода, которое предоставляет полезные инструменты для классификации, запросов и отчётности по информации, но это лишь вспомогательные функции архитектуры системы.

Помощь? Это возмутительно.

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

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

Вот в чём твоя проблема.

Что ты имеешь в виду?

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

Это просто безумие. Как создать бизнес-правила, которые не используют эти инструменты?

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

Так как же получить бизнес-правила, не зная, какими инструментами пользоваться?

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

Ты несёшь чепуху.

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

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

Это верно во время исполнения. Но при компиляции нам нужна инверсия зависимостей. Исходный код руководящих принципов высокого уровня не должен упоминать исходный код низкоуровневых рекомендаций.

Давай! Как можно позвонить, не упомянув об этом?

Конечно, без проблем. Вот что такое объектно-ориентированное дело.

Объектно-ориентированное — это создание реальных моделей, объединение данных, функциональности и целостных объектов. Речь идёт об организации кода в интуитивно понятную структуру.

Так говорят?

Как мы все знаем, это очевидная истина.

Да, это возможно, однако, используя объектно-ориентированные руководства, действительно возможно вызвать без упоминания об этом.

Ну, как это сделать?

В объектно-ориентированном проектировании объекты передают друг другу сообщения.

Да, конечно, верно.

Когда отправитель отправляет сообщение, он не знает тип получателя.

Это зависит от используемого языка. В Java отправитель знает как минимум базовый тип получателя. В Ruby отправитель, по крайней мере, знает, что получатель способен обрабатывать полученные сообщения.

Это правильно. В любом случае, отправитель не знает конкретного типа получателя.

Верно, так и есть.

Таким образом, отправитель может спроектировать приёмник для выполнения функции, не указывая конкретный тип приёмника.

Верно, верно. Я понимаю. Однако отправитель всё равно зависит от получателя.

Это верно во время исполнения. Однако при компиляции всё иначе. Исходный код отправителя не упоминает и не зависит от исходного кода получателя. Фактически, исходный код получателя зависит от исходного кода отправителя.

Ни в коем случае! Отправитель всё равно зависит от класса, который он отправляет.

Возможно, из какого-то исходного кода всё станет яснее. Следующий абзац написан на Java. Первым — отправитель:

Вот приёмник:

Примечание: Получатель зависит от отправителя, Специфичный приемник зависит от отправителя, и в адрес отправителя нет информации, связанной с получателем.

Да, но вы врёте, вы поставили интерфейс получателя в класс отправителя.

Ты начинаешь понимать.

Что ты знаешь?

Конечно, это принцип архитектуры. У отправителя есть интерфейс, который должен реализовать получатель.

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

Вложенные классы — это лишь один из способов достижения цели, есть и другие способы.

Подожди минутку. Какое это имеет отношение к базам данных? Мы начали говорить о базах данных.

Давайте подробнее рассмотрим код. Первое — простое правило бизнеса:

Бизнес-правила не имеют большого значения.

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

Итак, что же такое Gateway?

Он предоставляет все методы доступа к данным через бизнес-правила. Реализуйте его следующим образом:

Примечание: это в бизнес-правилах.

Хорошо, что такое класс «Что-то»?

Он представляет собой простой бизнес-объект. Я помещаю это в сущности.

В конечном итоге реализация BusinessRuleGateway, этот класс знает настоящую базу данных:

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

Ну, кажется, я понял. Вы просто используете полиморфизм, чтобы скрыть факт, что база данных реализована из бизнес-правил. Тем не менее, интерфейс для обеспечения всех инструментов баз данных для бизнес-правил всё ещё необходим.

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

Да, но если нужно использовать все инструменты для всех бизнес-правил, просто вставьте инструмент в интерфейс шлюза.

, думаю, ты ещё не понимаешь.

Понять что? Это уже ясно.

Каждое бизнес-правило определяет только один интерфейс для инструментов доступа к данным, которые ему нужны.

Погоди-ка, что скажешь?

Это принцип разделения интерфейсов. Каждый класс бизнес-правил использует только определённые возможности базы данных. Таким образом, интерфейсы, предоставляемые каждым бизнес-правилом, имеют доступ только к соответствующим объектам.

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

Отлично, ты начинаешь понимать.

Но это слишком грязно и пустая трата времени. Зачем это делать?

Это организовано и экономит время.

Давай, возьми много кода ради самого кода.

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

Что это значит?

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

Да, я так и думал.

Вы же хотите принимать решения о базах данных, веб-серверах и фреймворках, верно?

Да, вы говорите, что всё это не имеет значения. Просто нерелевантный контент.

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

Но сначала нужно решить, какие именно!

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

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

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

Ерунда, я совсем не понимаю, что ты имеешь в виду.

Ну, внимательно изучите эту статью, иначе придётся ждать ещё 10 лет, чтобы разобраться.