💡 Инструкция: Выберите один ответ из пяти. Время — 85 минут. У каждого задания ровно один правильный вариант. Фрагменты рассчитаны на Ruby 4.0.6; задания Rails — на Rails 8.1.3. После завершения откроются общий процент, 6 тематических результатов и разбор всех ответов.
Вопрос 1 из 30
Что произойдёт после последней строки в примере по теме «Границы домена»? Выберите связку, в которой верны и основной вывод, и его обоснование.
Ruby Ruby — Границы домена Копировать
# Проследите выполнение и выберите точный результат.
module Checkout
class PlaceOrder
def initialize(catalog:, payments:)
@catalog, @payments = catalog, payments
end
def call(command)
# предметная последовательность
end
end
end
Команда Checkout использует интерфейсы каталога, цены и платежа, не отдавая контроллеру порядок бизнес-шагов. Это объясняется тем, что граница домена объединяет данные и правила, которые меняются вместе; Rails-модель или таблица не обязаны совпадать с этой границей.
Команда Checkout использует интерфейсы каталога, цены и платежа, не отдавая контроллеру порядок бизнес-шагов. Это объясняется тем, что направление зависимостей должно вести от деталей к устойчивому интерфейсу домена; константная автозагрузка не заменяет архитектурного правила.
Размер thread pool не превышает доступный pool БД, поэтому каждый рабочий поток может получить соединение. Это объясняется тем, что граница домена объединяет данные и правила, которые меняются вместе; Rails-модель или таблица не обязаны совпадать с этой границей.
Команда Checkout использует интерфейсы каталога, цены и платежа, не отдавая контроллеру порядок бизнес-шагов. Это объясняется тем, что модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу.
Класс принимает gateway через конструктор и не создаёт конкретный HTTP-клиент внутри метода. Это объясняется тем, что граница домена объединяет данные и правила, которые меняются вместе; Rails-модель или таблица не обязаны совпадать с этой границей.
Вопрос 2 из 30
Какая трассировка кода по теме «Сервисные объекты» не теряет важную деталь? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Ruby Ruby — Сервисные объекты Копировать
# Проследите выполнение и выберите точный результат.
result = Orders::Cancel.call(order: order, actor: current_user)
case result
in Success(order:)
render json: order
in Failure(code:, message:)
render json: { error: code, message: message }, status: :conflict
end
Результат команды различает success и domain error, не возвращая неоднозначный nil. Причина такого результата: пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание.
Класс принимает gateway через конструктор и не создаёт конкретный HTTP-клиент внутри метода. Причина такого результата: сервисный объект полезен для законченной операции с явными входами и результатом; класс `SomethingService` без границ лишь переносит процедурный код.
Billing публикует команду, а Orders не обращается напрямую к внутренней модели Charge. Причина такого результата: сервисный объект полезен для законченной операции с явными входами и результатом; класс `SomethingService` без границ лишь переносит процедурный код.
Результат команды различает success и domain error, не возвращая неоднозначный nil. Причина такого результата: сервисный объект полезен для законченной операции с явными входами и результатом; класс `SomethingService` без границ лишь переносит процедурный код.
Результат команды различает success и domain error, не возвращая неоднозначный nil. Причина такого результата: модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу.
Вопрос 4 из 30
Что произойдёт после последней строки в примере по теме «Модульный монолит»? Правильным считается только полностью согласованное утверждение.
Ruby Ruby — Модульный монолит Копировать
# Проследите выполнение и выберите точный результат.
module Billing
module Commands; end
def self.charge(order_id:, amount_cents:)
Commands::Charge.call(order_id:, amount_cents:)
end
private_constant :Commands
end
Billing публикует команду, а Orders не обращается напрямую к внутренней модели Charge. Механизм результата таков: модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу.
Billing публикует команду, а Orders не обращается напрямую к внутренней модели Charge. Механизм результата таков: пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание.
Billing публикует команду, а Orders не обращается напрямую к внутренней модели Charge. Механизм результата таков: направление зависимостей должно вести от деталей к устойчивому интерфейсу домена; константная автозагрузка не заменяет архитектурного правила.
Результат команды различает success и domain error, не возвращая неоднозначный nil. Механизм результата таков: модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу.
Класс принимает gateway через конструктор и не создаёт конкретный HTTP-клиент внутри метода. Механизм результата таков: модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу.
Вопрос 5 из 30
Как следует прочитать результат показанного примера «Контроль ресурсов»? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Ruby Ruby — Контроль ресурсов Копировать
# Проследите выполнение и выберите точный результат.
threads_count = Integer(ENV.fetch('RAILS_MAX_THREADS', 5))
db_pool = ActiveRecord::Base.connection_pool.size
abort "DB pool #{db_pool} < threads #{threads_count}" if db_pool < threads_count
p [threads_count, db_pool]
Класс принимает gateway через конструктор и не создаёт конкретный HTTP-клиент внутри метода. Наблюдение согласуется с тем, что пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание.
Размер thread pool не превышает доступный pool БД, поэтому каждый рабочий поток может получить соединение. Наблюдение согласуется с тем, что пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание.
Размер thread pool не превышает доступный pool БД, поэтому каждый рабочий поток может получить соединение. Наблюдение согласуется с тем, что модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу.
Размер thread pool не превышает доступный pool БД, поэтому каждый рабочий поток может получить соединение. Наблюдение согласуется с тем, что сервисный объект полезен для законченной операции с явными входами и результатом; класс `SomethingService` без границ лишь переносит процедурный код.
Команда Checkout использует интерфейсы каталога, цены и платежа, не отдавая контроллеру порядок бизнес-шагов. Наблюдение согласуется с тем, что пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание.
Вопрос 6 из 30
Проследите выполнение фрагмента. Какой результат верен для темы «Масштабирование решения»? Верный вариант не содержит частично правильной подмены причины или следствия.
Ruby Ruby — Масштабирование решения Копировать
# Проследите выполнение и выберите точный результат.
key = "report:#{report.id}:v#{report.lock_version}"
Rails.cache.fetch(key, expires_in: 5.minutes) do
ReportPresenter.new(report).as_json
end
Ключ включает идентификатор и версию отчёта, а общее хранилище кэша позволяет разным web-процессам получить согласованное значение. Этот вывод опирается на правило: сервисный объект полезен для законченной операции с явными входами и результатом; класс `SomethingService` без границ лишь переносит процедурный код.
Команда Checkout использует интерфейсы каталога, цены и платежа, не отдавая контроллеру порядок бизнес-шагов. Этот вывод опирается на правило: масштабирование требует знать состояние процесса: локальный кэш, файлы и singleton не разделяются между экземплярами, а общая база становится координационной точкой.
Ключ включает идентификатор и версию отчёта, а общее хранилище кэша позволяет разным web-процессам получить согласованное значение. Этот вывод опирается на правило: масштабирование требует знать состояние процесса: локальный кэш, файлы и singleton не разделяются между экземплярами, а общая база становится координационной точкой.
Размер thread pool не превышает доступный pool БД, поэтому каждый рабочий поток может получить соединение. Этот вывод опирается на правило: масштабирование требует знать состояние процесса: локальный кэш, файлы и singleton не разделяются между экземплярами, а общая база становится координационной точкой.
Ключ включает идентификатор и версию отчёта, а общее хранилище кэша позволяет разным web-процессам получить согласованное значение. Этот вывод опирается на правило: пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание.
Вопрос 8 из 30
Какой рабочий сбой вероятнее всего связан именно с механизмом «Сервисные объекты»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Сервисные объекты Копировать
# Обычный запуск проходит. Найдите скрытый риск.
result = Orders::Cancel.call(order: order, actor: current_user)
case result
in Success(order:)
render json: order
in Failure(code:, message:)
render json: { error: code, message: message }, status: :conflict
end
Сервис, который читает глобальные params/current_user и запускает callbacks, трудно переиспользовать и тестировать вне контроллера. Этот риск связан с тем, что сервисный объект полезен для законченной операции с явными входами и результатом; класс `SomethingService` без границ лишь переносит процедурный код.
Сервис, который читает глобальные params/current_user и запускает callbacks, трудно переиспользовать и тестировать вне контроллера. Этот риск связан с тем, что модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу.
Общий ApplicationRecord для всех таблиц позволяет любому модулю обходить публичные операции соседа и ломать его инварианты. Этот риск связан с тем, что сервисный объект полезен для законченной операции с явными входами и результатом; класс `SomethingService` без границ лишь переносит процедурный код.
Сервис, который читает глобальные params/current_user и запускает callbacks, трудно переиспользовать и тестировать вне контроллера. Этот риск связан с тем, что пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание.
Разделение только по техническим папкам оставляет одно бизнес-изменение разбросанным по controllers/models/jobs и связанным callbacks. Этот риск связан с тем, что сервисный объект полезен для законченной операции с явными входами и результатом; класс `SomethingService` без границ лишь переносит процедурный код.
Вопрос 9 из 30
Какой рабочий сбой вероятнее всего связан именно с механизмом «Зависимости»? Выберите связку, в которой верны и основной вывод, и его обоснование.
Ruby Ruby — Зависимости Копировать
# Обычный запуск проходит. Найдите скрытый риск.
class PriceImporter
def initialize(gateway:)
@gateway = gateway
end
def call(sku)
Price.new(@gateway.fetch(sku))
end
end
Глобальный singleton-клиент с изменяемой конфигурацией связывает тесты, tenants и потоки одним состоянием. Уязвимое место возникает потому, что модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу.
In-memory флаг «задание уже выполнено» работает в одном процессе и дублирует эффект после горизонтального масштабирования. Уязвимое место возникает потому, что направление зависимостей должно вести от деталей к устойчивому интерфейсу домена; константная автозагрузка не заменяет архитектурного правила.
Глобальный singleton-клиент с изменяемой конфигурацией связывает тесты, tenants и потоки одним состоянием. Уязвимое место возникает потому, что пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание.
Увеличение Puma threads с 5 до 50 при pool=5 создаёт очередь внутри приложения и таймауты, хотя CPU свободен. Уязвимое место возникает потому, что направление зависимостей должно вести от деталей к устойчивому интерфейсу домена; константная автозагрузка не заменяет архитектурного правила.
Глобальный singleton-клиент с изменяемой конфигурацией связывает тесты, tenants и потоки одним состоянием. Уязвимое место возникает потому, что направление зависимостей должно вести от деталей к устойчивому интерфейсу домена; константная автозагрузка не заменяет архитектурного правила.
Вопрос 10 из 30
Какое допущение делает этот код по теме «Модульный монолит» ненадёжным? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Модульный монолит Копировать
# Обычный запуск проходит. Найдите скрытый риск.
module Billing
module Commands; end
def self.charge(order_id:, amount_cents:)
Commands::Charge.call(order_id:, amount_cents:)
end
private_constant :Commands
end
Общий ApplicationRecord для всех таблиц позволяет любому модулю обходить публичные операции соседа и ломать его инварианты. К такому сбою приводит правило: модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу.
Сервис, который читает глобальные params/current_user и запускает callbacks, трудно переиспользовать и тестировать вне контроллера. К такому сбою приводит правило: модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу.
Общий ApplicationRecord для всех таблиц позволяет любому модулю обходить публичные операции соседа и ломать его инварианты. К такому сбою приводит правило: пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание.
Общий ApplicationRecord для всех таблиц позволяет любому модулю обходить публичные операции соседа и ломать его инварианты. К такому сбою приводит правило: направление зависимостей должно вести от деталей к устойчивому интерфейсу домена; константная автозагрузка не заменяет архитектурного правила.
In-memory флаг «задание уже выполнено» работает в одном процессе и дублирует эффект после горизонтального масштабирования. К такому сбою приводит правило: модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу.
Вопрос 11 из 30
Какой отказ связан с причиной в коде, а не с внешним шумом, в теме «Контроль ресурсов»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Контроль ресурсов Копировать
# Обычный запуск проходит. Найдите скрытый риск.
threads_count = Integer(ENV.fetch('RAILS_MAX_THREADS', 5))
db_pool = ActiveRecord::Base.connection_pool.size
abort "DB pool #{db_pool} < threads #{threads_count}" if db_pool < threads_count
p [threads_count, db_pool]
Увеличение Puma threads с 5 до 50 при pool=5 создаёт очередь внутри приложения и таймауты, хотя CPU свободен. Источник риска: сервисный объект полезен для законченной операции с явными входами и результатом; класс `SomethingService` без границ лишь переносит процедурный код.
Глобальный singleton-клиент с изменяемой конфигурацией связывает тесты, tenants и потоки одним состоянием. Источник риска: пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание.
Увеличение Puma threads с 5 до 50 при pool=5 создаёт очередь внутри приложения и таймауты, хотя CPU свободен. Источник риска: пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание.
In-memory флаг «задание уже выполнено» работает в одном процессе и дублирует эффект после горизонтального масштабирования. Источник риска: пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание.
Увеличение Puma threads с 5 до 50 при pool=5 создаёт очередь внутри приложения и таймауты, хотя CPU свободен. Источник риска: модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу.
Вопрос 12 из 30
Что может сломаться при переносе этого решения «Масштабирование решения» в рабочую систему? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Ruby Ruby — Масштабирование решения Копировать
# Обычный запуск проходит. Найдите скрытый риск.
key = "report:#{report.id}:v#{report.lock_version}"
Rails.cache.fetch(key, expires_in: 5.minutes) do
ReportPresenter.new(report).as_json
end
In-memory флаг «задание уже выполнено» работает в одном процессе и дублирует эффект после горизонтального масштабирования. Проблема возникает из-за того, что пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание.
In-memory флаг «задание уже выполнено» работает в одном процессе и дублирует эффект после горизонтального масштабирования. Проблема возникает из-за того, что сервисный объект полезен для законченной операции с явными входами и результатом; класс `SomethingService` без границ лишь переносит процедурный код.
Общий ApplicationRecord для всех таблиц позволяет любому модулю обходить публичные операции соседа и ломать его инварианты. Проблема возникает из-за того, что масштабирование требует знать состояние процесса: локальный кэш, файлы и singleton не разделяются между экземплярами, а общая база становится координационной точкой.
In-memory флаг «задание уже выполнено» работает в одном процессе и дублирует эффект после горизонтального масштабирования. Проблема возникает из-за того, что масштабирование требует знать состояние процесса: локальный кэш, файлы и singleton не разделяются между экземплярами, а общая база становится координационной точкой.
Сервис, который читает глобальные params/current_user и запускает callbacks, трудно переиспользовать и тестировать вне контроллера. Проблема возникает из-за того, что масштабирование требует знать состояние процесса: локальный кэш, файлы и singleton не разделяются между экземплярами, а общая база становится координационной точкой.
Вопрос 13 из 30
Какое свойство Ruby или Rails определяет результат примера «Границы домена»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу. Поэтому команда Checkout использует интерфейсы каталога, цены и платежа, не отдавая контроллеру порядок бизнес-шагов.
Направление зависимостей должно вести от деталей к устойчивому интерфейсу домена; константная автозагрузка не заменяет архитектурного правила. Поэтому команда Checkout использует интерфейсы каталога, цены и платежа, не отдавая контроллеру порядок бизнес-шагов.
Граница домена объединяет данные и правила, которые меняются вместе; Rails-модель или таблица не обязаны совпадать с этой границей. Поэтому размер thread pool не превышает доступный pool БД, поэтому каждый рабочий поток может получить соединение.
Граница домена объединяет данные и правила, которые меняются вместе; Rails-модель или таблица не обязаны совпадать с этой границей. Поэтому класс принимает gateway через конструктор и не создаёт конкретный HTTP-клиент внутри метода.
Граница домена объединяет данные и правила, которые меняются вместе; Rails-модель или таблица не обязаны совпадать с этой границей. Поэтому команда Checkout использует интерфейсы каталога, цены и платежа, не отдавая контроллеру порядок бизнес-шагов.
Вопрос 14 из 30
Как сформулировать правило блока «Сервисные объекты» без лишних обещаний? Нужен вариант без логического разрыва между первой и второй частью.
Пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание. Из этого следует, что результат команды различает success и domain error, не возвращая неоднозначный nil.
Сервисный объект полезен для законченной операции с явными входами и результатом; класс `SomethingService` без границ лишь переносит процедурный код. Из этого следует, что billing публикует команду, а Orders не обращается напрямую к внутренней модели Charge.
Модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу. Из этого следует, что результат команды различает success и domain error, не возвращая неоднозначный nil.
Сервисный объект полезен для законченной операции с явными входами и результатом; класс `SomethingService` без границ лишь переносит процедурный код. Из этого следует, что результат команды различает success и domain error, не возвращая неоднозначный nil.
Сервисный объект полезен для законченной операции с явными входами и результатом; класс `SomethingService` без границ лишь переносит процедурный код. Из этого следует, что класс принимает gateway через конструктор и не создаёт конкретный HTTP-клиент внутри метода.
Вопрос 16 из 30
Какой механизм отделяет верный разбор от похожего, но ошибочного объяснения «Модульный монолит»? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу. Именно поэтому класс принимает gateway через конструктор и не создаёт конкретный HTTP-клиент внутри метода.
Модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу. Именно поэтому результат команды различает success и domain error, не возвращая неоднозначный nil.
Пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание. Именно поэтому billing публикует команду, а Orders не обращается напрямую к внутренней модели Charge.
Модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу. Именно поэтому billing публикует команду, а Orders не обращается напрямую к внутренней модели Charge.
Направление зависимостей должно вести от деталей к устойчивому интерфейсу домена; константная автозагрузка не заменяет архитектурного правила. Именно поэтому billing публикует команду, а Orders не обращается напрямую к внутренней модели Charge.
Вопрос 17 из 30
Какой принцип темы «Контроль ресурсов» переносится на другие примеры того же типа? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание. Это правило даёт такой результат: команда Checkout использует интерфейсы каталога, цены и платежа, не отдавая контроллеру порядок бизнес-шагов.
Сервисный объект полезен для законченной операции с явными входами и результатом; класс `SomethingService` без границ лишь переносит процедурный код. Это правило даёт такой результат: размер thread pool не превышает доступный pool БД, поэтому каждый рабочий поток может получить соединение.
Пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание. Это правило даёт такой результат: размер thread pool не превышает доступный pool БД, поэтому каждый рабочий поток может получить соединение.
Пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание. Это правило даёт такой результат: класс принимает gateway через конструктор и не создаёт конкретный HTTP-клиент внутри метода.
Модульный монолит сохраняет единое развёртывание, но требует проверяемых границ кода и данных; одни namespaces не препятствуют прямому доступу. Это правило даёт такой результат: размер thread pool не превышает доступный pool БД, поэтому каждый рабочий поток может получить соединение.
Вопрос 18 из 30
Почему показанный фрагмент «Масштабирование решения» ведёт себя именно так? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Масштабирование требует знать состояние процесса: локальный кэш, файлы и singleton не разделяются между экземплярами, а общая база становится координационной точкой. Практическое следствие правила: размер thread pool не превышает доступный pool БД, поэтому каждый рабочий поток может получить соединение.
Масштабирование требует знать состояние процесса: локальный кэш, файлы и singleton не разделяются между экземплярами, а общая база становится координационной точкой. Практическое следствие правила: команда Checkout использует интерфейсы каталога, цены и платежа, не отдавая контроллеру порядок бизнес-шагов.
Пулы потоков, соединений, файлов и внешние лимиты образуют общий ресурсный бюджет; масштабирование одного слоя без остальных увеличивает ожидание. Практическое следствие правила: ключ включает идентификатор и версию отчёта, а общее хранилище кэша позволяет разным web-процессам получить согласованное значение.
Сервисный объект полезен для законченной операции с явными входами и результатом; класс `SomethingService` без границ лишь переносит процедурный код. Практическое следствие правила: ключ включает идентификатор и версию отчёта, а общее хранилище кэша позволяет разным web-процессам получить согласованное значение.
Масштабирование требует знать состояние процесса: локальный кэш, файлы и singleton не разделяются между экземплярами, а общая база становится координационной точкой. Практическое следствие правила: ключ включает идентификатор и версию отчёта, а общее хранилище кэша позволяет разным web-процессам получить согласованное значение.
Вопрос 19 из 30
Какое изменение устраняет причину проблемы в теме «Границы домена», а не маскирует симптом? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.
Ruby Ruby — Границы домена Копировать
# Выберите изменение, которое исправляет причину.
module Checkout
class PlaceOrder
def initialize(catalog:, payments:)
@catalog, @payments = catalog, payments
end
def call(command)
# предметная последовательность
end
end
end
Назвать несколько ключевых возможностей бизнеса, определить владельца данных/инвариантов и запретить прямые обходы их публичного интерфейса. Так закрывается риск: общий ApplicationRecord для всех таблиц позволяет любому модулю обходить публичные операции соседа и ломать его инварианты.
Выносить действительно общее состояние в подходящее хранилище, но избегать распределённой блокировки там, где достаточно уникального ограничения. Так закрывается риск: разделение только по техническим папкам оставляет одно бизнес-изменение разбросанным по controllers/models/jobs и связанным callbacks.
Назвать несколько ключевых возможностей бизнеса, определить владельца данных/инвариантов и запретить прямые обходы их публичного интерфейса. Так закрывается риск: разделение только по техническим папкам оставляет одно бизнес-изменение разбросанным по controllers/models/jobs и связанным callbacks.
Назвать несколько ключевых возможностей бизнеса, определить владельца данных/инвариантов и запретить прямые обходы их публичного интерфейса. Так закрывается риск: сервис, который читает глобальные params/current_user и запускает callbacks, трудно переиспользовать и тестировать вне контроллера.
Передавать зависимости и входные данные явно, вернуть небольшой типизированный результат и оставить HTTP-преобразование контроллеру. Так закрывается риск: разделение только по техническим папкам оставляет одно бизнес-изменение разбросанным по controllers/models/jobs и связанным callbacks.
Вопрос 20 из 30
Какое инженерное решение лучше всего соответствует механизму «Сервисные объекты»? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Сервисные объекты Копировать
# Выберите изменение, которое исправляет причину.
result = Orders::Cancel.call(order: order, actor: current_user)
case result
in Success(order:)
render json: order
in Failure(code:, message:)
render json: { error: code, message: message }, status: :conflict
end
Передавать зависимости и входные данные явно, вернуть небольшой типизированный результат и оставить HTTP-преобразование контроллеру. Это изменение устраняет проблему: сервис, который читает глобальные params/current_user и запускает callbacks, трудно переиспользовать и тестировать вне контроллера.
Назвать несколько ключевых возможностей бизнеса, определить владельца данных/инвариантов и запретить прямые обходы их публичного интерфейса. Это изменение устраняет проблему: сервис, который читает глобальные params/current_user и запускает callbacks, трудно переиспользовать и тестировать вне контроллера.
Передавать зависимости и входные данные явно, вернуть небольшой типизированный результат и оставить HTTP-преобразование контроллеру. Это изменение устраняет проблему: разделение только по техническим папкам оставляет одно бизнес-изменение разбросанным по controllers/models/jobs и связанным callbacks.
Передавать зависимости и входные данные явно, вернуть небольшой типизированный результат и оставить HTTP-преобразование контроллеру. Это изменение устраняет проблему: общий ApplicationRecord для всех таблиц позволяет любому модулю обходить публичные операции соседа и ломать его инварианты.
Выносить действительно общее состояние в подходящее хранилище, но избегать распределённой блокировки там, где достаточно уникального ограничения. Это изменение устраняет проблему: сервис, который читает глобальные params/current_user и запускает callbacks, трудно переиспользовать и тестировать вне контроллера.
Вопрос 21 из 30
Какой вариант решения «Зависимости» останется понятным при сопровождении? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Зависимости Копировать
# Выберите изменение, которое исправляет причину.
class PriceImporter
def initialize(gateway:)
@gateway = gateway
end
def call(sku)
Price.new(@gateway.fetch(sku))
end
end
Ввести узкие порты на границах сети/БД и собирать конкретные адаптеры в composition root. Такая правка нужна из-за риска: глобальный singleton-клиент с изменяемой конфигурацией связывает тесты, tenants и потоки одним состоянием.
Считать end-to-end concurrency по самому узкому ресурсу, задавать таймауты/обратное давление и наблюдать очереди. Такая правка нужна из-за риска: глобальный singleton-клиент с изменяемой конфигурацией связывает тесты, tenants и потоки одним состоянием.
Ввести узкие порты на границах сети/БД и собирать конкретные адаптеры в composition root. Такая правка нужна из-за риска: увеличение Puma threads с 5 до 50 при pool=5 создаёт очередь внутри приложения и таймауты, хотя CPU свободен.
Определить публичные точки входа, статически проверять запрещённые константные зависимости и владение таблицами. Такая правка нужна из-за риска: глобальный singleton-клиент с изменяемой конфигурацией связывает тесты, tenants и потоки одним состоянием.
Ввести узкие порты на границах сети/БД и собирать конкретные адаптеры в composition root. Такая правка нужна из-за риска: in-memory флаг «задание уже выполнено» работает в одном процессе и дублирует эффект после горизонтального масштабирования.
Вопрос 22 из 30
Какое исправление уменьшает риск, не скрывая исходное поведение «Модульный монолит»? В правильном ответе вторая часть действительно объясняет или проверяет первую.
Ruby Ruby — Модульный монолит Копировать
# Выберите изменение, которое исправляет причину.
module Billing
module Commands; end
def self.charge(order_id:, amount_cents:)
Commands::Charge.call(order_id:, amount_cents:)
end
private_constant :Commands
end
Определить публичные точки входа, статически проверять запрещённые константные зависимости и владение таблицами. Решение адресует следующий дефект: общий ApplicationRecord для всех таблиц позволяет любому модулю обходить публичные операции соседа и ломать его инварианты.
Передавать зависимости и входные данные явно, вернуть небольшой типизированный результат и оставить HTTP-преобразование контроллеру. Решение адресует следующий дефект: общий ApplicationRecord для всех таблиц позволяет любому модулю обходить публичные операции соседа и ломать его инварианты.
Определить публичные точки входа, статически проверять запрещённые константные зависимости и владение таблицами. Решение адресует следующий дефект: in-memory флаг «задание уже выполнено» работает в одном процессе и дублирует эффект после горизонтального масштабирования.
Определить публичные точки входа, статически проверять запрещённые константные зависимости и владение таблицами. Решение адресует следующий дефект: сервис, который читает глобальные params/current_user и запускает callbacks, трудно переиспользовать и тестировать вне контроллера.
Считать end-to-end concurrency по самому узкому ресурсу, задавать таймауты/обратное давление и наблюдать очереди. Решение адресует следующий дефект: общий ApplicationRecord для всех таблиц позволяет любому модулю обходить публичные операции соседа и ломать его инварианты.
Вопрос 23 из 30
Как исправить реализацию «Контроль ресурсов» без новой скрытой зависимости? Нужен вариант без логического разрыва между первой и второй частью.
Ruby Ruby — Контроль ресурсов Копировать
# Выберите изменение, которое исправляет причину.
threads_count = Integer(ENV.fetch('RAILS_MAX_THREADS', 5))
db_pool = ActiveRecord::Base.connection_pool.size
abort "DB pool #{db_pool} < threads #{threads_count}" if db_pool < threads_count
p [threads_count, db_pool]
Считать end-to-end concurrency по самому узкому ресурсу, задавать таймауты/обратное давление и наблюдать очереди. Именно эта мера закрывает риск: увеличение Puma threads с 5 до 50 при pool=5 создаёт очередь внутри приложения и таймауты, хотя CPU свободен.
Считать end-to-end concurrency по самому узкому ресурсу, задавать таймауты/обратное давление и наблюдать очереди. Именно эта мера закрывает риск: in-memory флаг «задание уже выполнено» работает в одном процессе и дублирует эффект после горизонтального масштабирования.
Определить публичные точки входа, статически проверять запрещённые константные зависимости и владение таблицами. Именно эта мера закрывает риск: увеличение Puma threads с 5 до 50 при pool=5 создаёт очередь внутри приложения и таймауты, хотя CPU свободен.
Считать end-to-end concurrency по самому узкому ресурсу, задавать таймауты/обратное давление и наблюдать очереди. Именно эта мера закрывает риск: глобальный singleton-клиент с изменяемой конфигурацией связывает тесты, tenants и потоки одним состоянием.
Передавать зависимости и входные данные явно, вернуть небольшой типизированный результат и оставить HTTP-преобразование контроллеру. Именно эта мера закрывает риск: увеличение Puma threads с 5 до 50 при pool=5 создаёт очередь внутри приложения и таймауты, хотя CPU свободен.
Вопрос 24 из 30
Какой вариант решения «Масштабирование решения» останется понятным при сопровождении? Верный вариант не содержит частично правильной подмены причины или следствия.
Ruby Ruby — Масштабирование решения Копировать
# Выберите изменение, которое исправляет причину.
key = "report:#{report.id}:v#{report.lock_version}"
Rails.cache.fetch(key, expires_in: 5.minutes) do
ReportPresenter.new(report).as_json
end
Передавать зависимости и входные данные явно, вернуть небольшой типизированный результат и оставить HTTP-преобразование контроллеру. После изменения не должен сохраняться риск: in-memory флаг «задание уже выполнено» работает в одном процессе и дублирует эффект после горизонтального масштабирования.
Назвать несколько ключевых возможностей бизнеса, определить владельца данных/инвариантов и запретить прямые обходы их публичного интерфейса. После изменения не должен сохраняться риск: in-memory флаг «задание уже выполнено» работает в одном процессе и дублирует эффект после горизонтального масштабирования.
Выносить действительно общее состояние в подходящее хранилище, но избегать распределённой блокировки там, где достаточно уникального ограничения. После изменения не должен сохраняться риск: in-memory флаг «задание уже выполнено» работает в одном процессе и дублирует эффект после горизонтального масштабирования.
Выносить действительно общее состояние в подходящее хранилище, но избегать распределённой блокировки там, где достаточно уникального ограничения. После изменения не должен сохраняться риск: общий ApplicationRecord для всех таблиц позволяет любому модулю обходить публичные операции соседа и ломать его инварианты.
Выносить действительно общее состояние в подходящее хранилище, но избегать распределённой блокировки там, где достаточно уникального ограничения. После изменения не должен сохраняться риск: сервис, который читает глобальные params/current_user и запускает callbacks, трудно переиспользовать и тестировать вне контроллера.
Вопрос 30 из 30
Что следует добавить в набор проверок по теме «Масштабирование решения», чтобы поймать редкий отказ? Нужен вариант без логического разрыва между первой и второй частью.
Проверить деградацию общего кэша: приложение должно сохранять корректность при cache miss или недоступности, если это заявлено. Такой контрпример нужен для решения: назвать несколько ключевых возможностей бизнеса, определить владельца данных/инвариантов и запретить прямые обходы их публичного интерфейса.
Проверить ошибку/таймаут адаптера: доменный слой не должен зависеть от класса исключения конкретной библиотеки. Такой контрпример нужен для решения: выносить действительно общее состояние в подходящее хранилище, но избегать распределённой блокировки там, где достаточно уникального ограничения.
Проверить деградацию общего кэша: приложение должно сохранять корректность при cache miss или недоступности, если это заявлено. Такой контрпример нужен для решения: выносить действительно общее состояние в подходящее хранилище, но избегать распределённой блокировки там, где достаточно уникального ограничения.
Проверить транзакцию между границами: локальная ACID-транзакция не должна маскировать распределённую координацию. Такой контрпример нужен для решения: выносить действительно общее состояние в подходящее хранилище, но избегать распределённой блокировки там, где достаточно уникального ограничения.
Проверить деградацию общего кэша: приложение должно сохранять корректность при cache miss или недоступности, если это заявлено. Такой контрпример нужен для решения: передавать зависимости и входные данные явно, вернуть небольшой типизированный результат и оставить HTTP-преобразование контроллеру.