Интервьюер: Как проектировать при изменении системных требований?

интервью задняя часть Архитектура
Интервьюер: Как проектировать при изменении системных требований?

интервьюер: Хочу задать вопрос, чем чаще встречаются проблемы в проекте

интервьюер:Теперь у меня есть система, которая будет выполнять различные действия в зависимости от входных параметров запроса. Однако это другое действие, вероятно, повлечет за собой изменение спроса.Как бы вы спроектировали эту систему?

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

интервьюер:Если бы вам разрешили оптимизировать, как бы вы спроектировали?

Кандидат: Я понимаю что ты имеешь в виду

Кандидат: В конечном счете, логика обработки относительно сложна, и слишком много суждений, если еще.

Кандидат: Хотя появляются новые требования, вы можете добавить, если еще решить их

Кандидат: Но вы хотите, чтобы система была более масштабируемой и ремонтопригодной.

Кандидат: Хотите, чтобы я придумал решение для решения подобных проблем

Кандидат:Правильно?

интервьюер:В порядке…

Кандидат: До этого большинство ищет в Интернете, как решить, если еще , большинство из них говорят, что это режим стратегии.

Кандидат: Но я не чувствую то же самое о примере, который я привел.Много раз это заканчивается после его прочтения.

Кандидат: На самом деле в проекте еще довольно много паттернов стратегий, которые могли быть использованы случайно (все-таки интерфейсно-ориентированное программирование)

Кандидат: И я думаю, что шаблон стратегии не является ключом к решению, если еще

Кандидат: Этот вопрос, подход в моем проекте: Режим цепочки ответственности

Кандидат: извлеките каждый процесс в процесс (который можно понимать как модуль или узел), а затем запрос будет помещен в контекст.

Кандидат: Например, если вы ранее поддерживали проект, он похож на разные каналы и другую логику.

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

Кандидат: Например, цепочка ответственности канала A: WhiteListProcess->DataAssembleProcess->ChannelAProcess->SendProcess

Кандидат: А цепочка ответственности канала B такова: WhiteListProcess->DataAssembleProcess->ChannelBProcess->SendProcess

Кандидат: В зависимости от цепочки ответственности в код могут быть встроены «скрипты».

Кандидат: Например, на SendProcess есть встроенный скрипт для отправки сообщений (скрипт может выбирать разных операторов для отправки сообщений). С помощью «сценария» изменения в логике могут вступить в силу без перезапуска.

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

Кандидат: Напишите модифицируемую логику на "скрипте" (по крайней мере, мы считаем, что скрипт отделен от реальной логики нашего приложения)

Кандидат: (Скрипт здесь я отношу к набору правил, это может быть dsl Drools, это может быть Groovy, это может быть aviator и т.д.)

интервьюер:В порядке…

Кандидат: В моей предыдущей компании использовались скрипты Groovy. Общая логика реализации такова: есть специальный фон для управления скриптом, а затем скрипт записывается в "центр распределенной конфигурации" (обновление в реальном времени), а клиент следит за тем, хранится ли скрипт в "центре распределенной конфигурации" "изменился.

Кандидат: если есть изменения, перекомпилируйте и загрузите скрипт через загрузчик классов Groovy и, наконец, поместите его в контейнер Spring для внешнего использования.

Кандидат: Система, за которую я сейчас отвечаю, - это способ справиться с бизнесом изменчивых и часто меняющихся требований (цепочка ответственности + механизм правил).

Кандидат: Но насколько я знаю, наш геймплейный бизнес сделал больше вещей в "цепочке ответственности"

Кандидат: «Цепочка ответственности» больше не прописана в коде, а спускается на платформу для выполнения «Сервисной оркестрации», то есть программист переходит в «Сервисную оркестровку фона» для настройки информации (настройки каждого узла цепочки обязанность)

Кандидат: Клиент, использующий «Оркестрацию услуг» в бизнес-системе, если при запросе передается идентификатор «Оркестрации услуг», код может выполняться в соответствии с процессом «Оркестрации услуг».

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

интервьюер: Тогда я понимаю

Добро пожаловать в мой публичный аккаунт WeChat【Java3y] Давайте поговорим о Java-интервью, серия онлайн-интервьюеров постоянно обновляется!

Серия [Онлайн-интервьюер-Мобильный терминал]Продолжаем обновлять два раза в неделю!

【Онлайн-интервьюер-компьютер】СерияПродолжаем обновлять два раза в неделю!

Оригинал это не просто! ! Проси три! !