Архитектура Kotlin-приложения — бесплатный тест онлайн

Вопрос 1 из 30

Какой архитектурный выигрыш у такой модели?

// Проследите фактическое выполнение без изменения кода.
@JvmInline value class AccountId(val value: String)

data class Account private constructor(val id: AccountId, val balance: Money) {
    companion object {
        fun open(id: AccountId): Account = Account(id, Money.ZERO)
    }
    fun debit(amount: Money): Account {
        require(amount > Money.ZERO && amount <= balance)
        return copy(balance = balance - amount)
    }
}

Невалидные переходы остаются внутри доменного типа, а новое состояние создаётся явно. Value class делает операции с балансом атомарными между потоками. Require превращает ошибку бизнеса в compile-time запрет для любого amount. Private constructor гарантирует, что данные в рассматриваемом случае не не придут из недоверенного источника. Data class автоматически сохраняет Account в базе после copy.

Вопрос 2 из 30

Какое объяснение результата «Доменный порт и internal adapter» выдерживает проверку соседними случаями?

// На ревью требуется объяснить причину поведения.
// domain module
data class Order(val id: String)
interface OrderRepository { suspend fun save(order: Order) }

// infrastructure module
internal interface Database { suspend fun insert(order: Order) }
internal class SqlOrderRepository(
    private val database: Database
) : OrderRepository {
    override suspend fun save(order: Order) = database.insert(order)
}

Из правил языка или API следует, что интерфейс автоматически исключает runtime-зависимость от драйвера из итогового приложения. Механика примера описывается утверждением: Internal не позволяет infrastructure тестировать класс. Семантика фрагмента приводит к тому, что domain module может напрямую использовать private SQL helpers через DI. Направление зависимостей должно следовать устойчивым политикам; реализация зависит от доменного порта, а не наоборот. Причина результата в том, что любая реализация интерфейса становится потокобезопасной.

Вопрос 3 из 30

Какая правка устраняет причину риска в «Атомарное обновление StateFlow», а не только его проявление?

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.flow.*
class Store(initial: AppState) {
    private val _state = MutableStateFlow(initial)
    val state: StateFlow<AppState> = _state.asStateFlow()
    fun dispatch(action: Action) { _state.update { reduce(it, action) } }
}

Оставить реализацию без изменений и закрепить тестом предположение: AsStateFlow делает исходный MutableStateFlow недоступным даже внутри Store. Спрятать участок за вспомогательной функцией, сохранив предположение: Update запускает каждый reducer на отдельном потоке. Вынести участок в отдельный метод, считая верным следующее: StateFlow сохраняет очередь всех Action автоматически. Сериализовать side effects отдельно, не выполнять сеть внутри update и публиковать immutable AppState. Перенести проверку в вызывающий код, исходя из того, что она гарантирует, что reducer будет вызван ровно один раз.

Вопрос 4 из 30

Какой сценарий выявит скрытое ограничение «Контекст запроса в корутине»?

Воспроизвести редкий сценарий, где достаточно увеличить текст каждого сообщения до полной копии request с секретами. Проверить границу полезности утверждения: Нужно заменить все suspend-функции блокирующими, чтобы поток не менялся. MDC-карта, изменённая внутри корутины без корректного context element update, может не сохраниться после suspension. Отдельно проверить предположение, что mDCContext гарантирует распределённый trace через сеть без заголовков. Проверить соседний случай: Один stack trace на startup объяснит последующие ошибки.

Вопрос 5 из 30

Какой побочный эффект существеннее остальных после правки «Автоматическая проверка зависимостей»: Формулировать несколько значимых правил с понятным сообщением, а спорные решения документировать ADR и проверять интеграционными сценариями?

Обратная сторона изменения состоит в том, что он запрещает reflection и DI независимо от настроенной политики. Решение оправдано лишь при условии: Он заменяет code review всех архитектурных решений. Автоматическая защита не даёт случайно размыть слои, но слишком жёсткие package-правила тормозят полезный рефакторинг. После правки останется ограничение: Он гарантирует отсутствие циклов данных в рабочей среде. Новый риск связан с тем, что он проверяет задержку выполнения между модулями.

Вопрос 6 из 30

Какой принцип выражен в `AppRuntime`?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.*
class AppRuntime(
    private val scope: CoroutineScope,
    private val jobs: List<BackgroundService>
) {
    fun start() = jobs.map { it.start(scope) }
    suspend fun stop() { scope.cancel(); scope.coroutineContext[Job]?.join() }
}

Join текущего Job в показанном сценарии безопасен и не может ждать самого себя. Фоновые сервисы получают общего владельца жизненного цикла с наблюдаемыми запуском и остановкой. Cancel немедленно убивает системные потоки без cleanup. Список jobs автоматически задаёт порядок завершения внешних ресурсов. Общий scope гарантирует, что сбой одного сервиса не затронет остальные независимо от Job.

Вопрос 7 из 30

Какой рефакторинг делает поведение «Доменный порт и internal adapter» предсказуемее?

// Сохраните назначение фрагмента, но укрепите его контракт.
// domain module
data class Order(val id: String)
interface OrderRepository { suspend fun save(order: Order) }

// infrastructure module
internal interface Database { suspend fun insert(order: Order) }
internal class SqlOrderRepository(
    private val database: Database
) : OrderRepository {
    override suspend fun save(order: Order) = database.insert(order)
}

Спрятать участок за вспомогательной функцией, сохранив предположение: Любая реализация интерфейса становится потокобезопасной. Проверять архитектурными тестами запрещённые imports и не создавать интерфейс без реальной границы/вариативности. Сохранить API и считать достаточным условие: Интерфейс автоматически исключает runtime-зависимость от драйвера из итогового приложения. Добавить защитную проверку перед фрагментом, поскольку domain module может напрямую использовать private SQL helpers через DI. Ограничиться поясняющим комментарием о том, что internal не позволяет infrastructure тестировать класс.

Вопрос 8 из 30

Какой редкий случай способен сломать наивную трактовку «Атомарное обновление StateFlow»?

Отдельно воспроизвести случай, в котором asStateFlow делает исходный MutableStateFlow недоступным даже внутри Store. Воспроизвести редкий сценарий, где stateFlow сохраняет очередь всех Action автоматически. Зафиксировать сценарий, где ожидается: Update запускает каждый reducer на отдельном потоке. Долгий reducer блокирует вызывающий поток и увеличивает повторы CAS; тяжёлые вычисления нужно подготовить до атомарного перехода. Добавить граничный тест на утверждение: Она гарантирует, что reducer будет вызван ровно один раз.

Вопрос 9 из 30

Какой риск не исчезает после правки «Контекст запроса в корутине»: Редактировать чувствительные поля, логировать решение один раз на границе и добавить SLO-метрики/спаны для зависимостей?

Богатая телеметрия сокращает MTTR, но увеличивает стоимость, объём данных и риск утечки, поэтому нужна схема и выборочная запись. Главный риск формулируют так: Нужно заменить все suspend-функции блокирующими, чтобы поток не менялся. Граница полезности решения описывается условием: Достаточно увеличить текст каждого сообщения до полной копии request с секретами. Цена упрощения проявится, если один stack trace на startup объяснит последующие ошибки. Практическое ограничение подхода: MDCContext гарантирует распределённый trace через сеть без заголовков.

Вопрос 10 из 30

Что произойдёт при запуске примера «Автоматическая проверка зависимостей»?

// Проследите фактическое выполнение без изменения кода.
@Test fun architecture_rules() {
    classes().that().resideInAPackage("..domain..")
        .should().onlyDependOnClassesThat(resideIn("..domain..", "kotlin.."))
        .check(importedClasses)
}

Он гарантирует отсутствие циклов данных в рабочей среде. Проверка ловит запрещённую исходную зависимость домена от инфраструктуры. Он проверяет задержку выполнения между модулями. Он заменяет code review всех архитектурных решений. Он запрещает reflection и DI независимо от настроенной политики.

Вопрос 11 из 30

Какой контракт снимает спор о причине поведения «Владелец фонового lifecycle»?

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.*
class AppRuntime(
    private val scope: CoroutineScope,
    private val jobs: List<BackgroundService>
) {
    fun start() = jobs.map { it.start(scope) }
    suspend fun stop() { scope.cancel(); scope.coroutineContext[Job]?.join() }
}

Механика примера описывается утверждением: Cancel немедленно убивает системные потоки без cleanup. Из правил языка или API следует, что общий scope гарантирует, что сбой одного сервиса не затронет остальные независимо от Job. Причина результата в том, что join текущего Job в показанном сценарии безопасен и не может ждать самого себя. Жизненный цикл приложения должен владеть корневыми scopes, supervision policy, shutdown timeout и сбором ошибок фоновых компонентов. Семантика фрагмента приводит к тому, что список jobs автоматически задаёт порядок завершения внешних ресурсов.

Вопрос 12 из 30

Какой контракт определяет наблюдаемый результат «Инварианты Account»?

// На ревью требуется объяснить причину поведения.
@JvmInline value class AccountId(val value: String)

data class Account private constructor(val id: AccountId, val balance: Money) {
    companion object {
        fun open(id: AccountId): Account = Account(id, Money.ZERO)
    }
    fun debit(amount: Money): Account {
        require(amount > Money.ZERO && amount <= balance)
        return copy(balance = balance - amount)
    }
}

Ключевым считают контракт: Require превращает ошибку бизнеса в compile-time запрет для любого amount. Объяснение опирается на утверждение: Private constructor гарантирует, что данные в рассматриваемом случае не не придут из недоверенного источника. Rich domain model защищает инварианты в месте изменения; внешние DTO и persistence objects не должны обходить фабрики бесконтрольно. Наблюдаемое поведение выводят из того, что value class делает операции с балансом атомарными между потоками. Здесь действует следующее правило: Data class автоматически сохраняет Account в базе после copy.

Вопрос 13 из 30

Что может усложниться в сопровождении после изменения «Атомарное обновление StateFlow»: Сериализовать side effects отдельно, не выполнять сеть внутри update и публиковать immutable AppState?

Единый store упрощает трассировку, но глобальное состояние создаёт широкие recomposition/подписки и связанность функций. Сопровождение усложнится, если окажется, что stateFlow сохраняет очередь всех Action автоматически. Решение оправдано лишь при условии: Она гарантирует, что reducer будет вызван ровно один раз. Компромисс состоит в утверждении: Update запускает каждый reducer на отдельном потоке. Обратная сторона изменения состоит в том, что asStateFlow делает исходный MutableStateFlow недоступным даже внутри Store.

Вопрос 14 из 30

Чего не хватает для полноценного расследования редких сбоев?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.*
suspend fun handle(request: Request): Response = withContext(MDCContext()) {
    logger.info { "start id=${request.id}" }
    service.execute(request)
}

Достаточно увеличить текст каждого сообщения до полной копии request с секретами. Один stack trace на startup объяснит последующие ошибки. Нужно заменить все suspend-функции блокирующими, чтобы поток не менялся. MDCContext гарантирует распределённый trace через сеть без заголовков. Нужны сквозной correlation id, структурированные ошибки, метрики задержек и трассы внешних вызовов.

Вопрос 15 из 30

Что точнее описывает механику фрагмента «Автоматическая проверка зависимостей»?

// На ревью требуется объяснить причину поведения.
@Test fun architecture_rules() {
    classes().that().resideInAPackage("..domain..")
        .should().onlyDependOnClassesThat(resideIn("..domain..", "kotlin.."))
        .check(importedClasses)
}

Механика примера описывается утверждением: Он гарантирует отсутствие циклов данных в рабочей среде. Здесь действует следующее правило: Он проверяет задержку выполнения между модулями. Такой результат объясняют тем, что он запрещает reflection и DI независимо от настроенной политики. Ключевым считают контракт: Он заменяет code review всех архитектурных решений. Архитектурные тесты фиксируют механически проверяемые ограничения: packages, modules, annotations и dependency direction.

Вопрос 16 из 30

Что стоит исправить в «Владелец фонового lifecycle» перед слиянием?

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.*
class AppRuntime(
    private val scope: CoroutineScope,
    private val jobs: List<BackgroundService>
) {
    fun start() = jobs.map { it.start(scope) }
    suspend fun stop() { scope.cancel(); scope.coroutineContext[Job]?.join() }
}

Сохранить API и считать достаточным условие: Общий scope гарантирует, что сбой одного сервиса не затронет остальные независимо от Job. Использовать SupervisorJob при независимости сервисов, хранить дочерние Jobs, задавать порядок stop/close и ограниченный graceful timeout. Спрятать участок за вспомогательной функцией, сохранив предположение: Join текущего Job в показанном сценарии безопасен и не может ждать самого себя. Ограничиться поясняющим комментарием о том, что cancel немедленно убивает системные потоки без cleanup. Добавить защитную проверку перед фрагментом, поскольку список jobs автоматически задаёт порядок завершения внешних ресурсов.

Вопрос 17 из 30

Какую правку выбрать, чтобы сохранить назначение «Инварианты Account» и убрать хрупкость?

// Сохраните назначение фрагмента, но укрепите его контракт.
@JvmInline value class AccountId(val value: String)

data class Account private constructor(val id: AccountId, val balance: Money) {
    companion object {
        fun open(id: AccountId): Account = Account(id, Money.ZERO)
    }
    fun debit(amount: Money): Account {
        require(amount > Money.ZERO && amount <= balance)
        return copy(balance = balance - amount)
    }
}

Передать ответственность владельцу вызова, предполагая, что data class автоматически сохраняет Account в базе после copy. Оставить структуру прежней, документировав утверждение: Private constructor гарантирует, что данные в рассматриваемом случае не не придут из недоверенного источника. Обернуть операцию проверкой и не менять основной контракт: Value class делает операции с балансом атомарными между потоками. Возвращать доменный результат для ожидаемого отказа, отделить Money currency и покрыть переходы property-based тестами. Зафиксировать текущее поведение регрессионным тестом: Require превращает ошибку бизнеса в compile-time запрет для любого amount.

Вопрос 18 из 30

Какой редкий случай способен сломать наивную трактовку «Доменный порт и internal adapter»?

Добавить граничный тест на утверждение: Internal не позволяет infrastructure тестировать класс. Отдельно воспроизвести случай, в котором любая реализация интерфейса становится потокобезопасной. Воспроизвести редкий сценарий, где domain module может напрямую использовать private SQL helpers через DI. Зафиксировать сценарий, где ожидается: Интерфейс автоматически исключает runtime-зависимость от драйвера из итогового приложения. Общий модуль contracts может превратиться в свалку DTO и связать всё со всем, если владение типами не определено.

Вопрос 19 из 30

Почему пример «Контекст запроса в корутине» даёт именно такой результат?

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.*
suspend fun handle(request: Request): Response = withContext(MDCContext()) {
    logger.info { "start id=${request.id}" }
    service.execute(request)
}

Поведение связывают с правилом: Нужно заменить все suspend-функции блокирующими, чтобы поток не менялся. Объяснение опирается на утверждение: MDCContext гарантирует распределённый trace через сеть без заголовков. Причину поведения формулируют так: Один stack trace на startup объяснит последующие ошибки. Семантика фрагмента приводит к тому, что достаточно увеличить текст каждого сообщения до полной копии request с секретами. Наблюдаемость связывает журналы, метрики и трассировки общими идентификаторами и сохраняет контекст при переключении корутин.

Вопрос 20 из 30

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

// Сохраните назначение фрагмента, но укрепите его контракт.
@Test fun architecture_rules() {
    classes().that().resideInAPackage("..domain..")
        .should().onlyDependOnClassesThat(resideIn("..domain..", "kotlin.."))
        .check(importedClasses)
}

Формулировать несколько значимых правил с понятным сообщением, а спорные решения документировать ADR и проверять интеграционными сценариями. Обернуть операцию проверкой и не менять основной контракт: Он запрещает reflection и DI независимо от настроенной политики. Зафиксировать текущее поведение регрессионным тестом: Он гарантирует отсутствие циклов данных в рабочей среде. Вынести участок в отдельный метод, считая верным следующее: Он проверяет задержку выполнения между модулями. Оставить структуру прежней, документировав утверждение: Он заменяет code review всех архитектурных решений.

Вопрос 21 из 30

Что добавить в регрессионный набор для «Владелец фонового lifecycle»?

Проверить соседний случай: Общий scope гарантирует, что сбой одного сервиса не затронет остальные независимо от Job. Отдельно проверить предположение, что cancel немедленно убивает системные потоки без cleanup. Попытка join корневого Job из его собственного ребёнка может создать ожидание; shutdown должен выполняться из внешнего владельца. Считать опасной границей ситуацию, где список jobs автоматически задаёт порядок завершения внешних ресурсов. Добавить регрессию на гипотезу: Join текущего Job в показанном сценарии безопасен и не может ждать самого себя.

Вопрос 22 из 30

Какой контрпример точнее всего показывает границу «Инварианты Account»?

Отдельно воспроизвести случай, в котором value class делает операции с балансом атомарными между потоками. Добавить граничный тест на утверждение: Private constructor гарантирует, что данные в рассматриваемом случае не не придут из недоверенного источника. Reflection/serializer может обойти private constructor или создать объект без фабрики, если инфраструктура настроена на это. Воспроизвести редкий сценарий, где data class автоматически сохраняет Account в базе после copy. Проверить границу полезности утверждения: Require превращает ошибку бизнеса в compile-time запрет для любого amount.

Вопрос 23 из 30

Что может усложниться в сопровождении после изменения «Доменный порт и internal adapter»: Проверять архитектурными тестами запрещённые imports и не создавать интерфейс без реальной границы/вариативности?

Компромисс состоит в утверждении: Интерфейс автоматически исключает runtime-зависимость от драйвера из итогового приложения. Обратная сторона изменения состоит в том, что любая реализация интерфейса становится потокобезопасной. Сопровождение усложнится, если окажется, что domain module может напрямую использовать private SQL helpers через DI. Решение оправдано лишь при условии: Internal не позволяет infrastructure тестировать класс. Модули ускоряют независимую сборку и защищают границы, но слишком мелкая нарезка увеличивает Gradle и навигационную стоимость.

Вопрос 24 из 30

Почему `update` предпочтительнее `state.value = reduce(state.value, action)` при конкуренции?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.flow.*
class Store(initial: AppState) {
    private val _state = MutableStateFlow(initial)
    val state: StateFlow<AppState> = _state.asStateFlow()
    fun dispatch(action: Action) { _state.update { reduce(it, action) } }
}

Она гарантирует, что reducer будет вызван ровно один раз. `update` атомарно повторяет преобразование при конфликте CAS и не теряет параллельную запись. AsStateFlow делает исходный MutableStateFlow недоступным даже внутри Store. StateFlow сохраняет очередь всех Action автоматически. Update запускает каждый reducer на отдельном потоке.

Вопрос 25 из 30

Какой сценарий выявит скрытое ограничение «Автоматическая проверка зависимостей»?

Отдельно проверить предположение, что он гарантирует отсутствие циклов данных в рабочей среде. Проверить границу полезности утверждения: Он заменяет code review всех архитектурных решений. Добавить тест на состояние, при котором он запрещает reflection и DI независимо от настроенной политики. Обход через reflection, service locator или сериализованный DTO может нарушить смысл границы, не создав прямого import. Воспроизвести редкий сценарий, где он проверяет задержку выполнения между модулями.

Вопрос 26 из 30

Какое ограничение сохранится после правки «Владелец фонового lifecycle»: Использовать SupervisorJob при независимости сервисов, хранить дочерние Jobs, задавать порядок stop/close и ограниченный graceful timeout?

Главный runtime добавляет инфраструктурный слой, но предотвращает утечки, потерянные ошибки и хаотичный порядок остановки. Практическое ограничение подхода: Cancel немедленно убивает системные потоки без cleanup. Новый риск связан с тем, что список jobs автоматически задаёт порядок завершения внешних ресурсов. Компромисс состоит в утверждении: Join текущего Job в показанном сценарии безопасен и не может ждать самого себя. Цена упрощения проявится, если общий scope гарантирует, что сбой одного сервиса не затронет остальные независимо от Job.

Вопрос 27 из 30

В «Инварианты Account» выбрали решение: Возвращать доменный результат для ожидаемого отказа, отделить Money currency и покрыть переходы property-based тестами. Какова его реальная цена?

Главная цена решения — необходимость учитывать, что value class делает операции с балансом атомарными между потоками. После правки останется ограничение: Private constructor гарантирует, что данные в рассматриваемом случае не не придут из недоверенного источника. Инварианты становятся надёжнее, но маппинг и явные операции увеличивают объём кода по сравнению с анемичной моделью. Граница полезности решения описывается условием: Data class автоматически сохраняет Account в базе после copy. Главный риск формулируют так: Require превращает ошибку бизнеса в compile-time запрет для любого amount.

Вопрос 28 из 30

Что защищает такая зависимость?

// Проследите фактическое выполнение без изменения кода.
// domain module
data class Order(val id: String)
interface OrderRepository { suspend fun save(order: Order) }

// infrastructure module
internal interface Database { suspend fun insert(order: Order) }
internal class SqlOrderRepository(
    private val database: Database
) : OrderRepository {
    override suspend fun save(order: Order) = database.insert(order)
}

Internal не позволяет infrastructure тестировать класс. Любая реализация интерфейса становится потокобезопасной. Интерфейс автоматически исключает runtime-зависимость от драйвера из итогового приложения. Domain module может напрямую использовать private SQL helpers через DI. Домен зависит от контракта, а не от SQL-реализации; инфраструктуру можно заменить.

Вопрос 29 из 30

Какое правило определяет поведение фрагмента «Атомарное обновление StateFlow»?

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.flow.*
class Store(initial: AppState) {
    private val _state = MutableStateFlow(initial)
    val state: StateFlow<AppState> = _state.asStateFlow()
    fun dispatch(action: Action) { _state.update { reduce(it, action) } }
}

Контракт здесь понимают так: AsStateFlow делает исходный MutableStateFlow недоступным даже внутри Store. StateFlow даёт атомарное текущее значение, но reducer должен быть чистым, потому что update может повторно вызвать лямбду. Причину поведения формулируют так: StateFlow сохраняет очередь всех Action автоматически. Семантика фрагмента приводит к тому, что она гарантирует, что reducer будет вызван ровно один раз. Причина результата в том, что update запускает каждый reducer на отдельном потоке.

Вопрос 30 из 30

Как укрепить «Контекст запроса в корутине», не переписывая соседние модули?

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.*
suspend fun handle(request: Request): Response = withContext(MDCContext()) {
    logger.info { "start id=${request.id}" }
    service.execute(request)
}

Перенести проверку в вызывающий код, исходя из того, что нужно заменить все suspend-функции блокирующими, чтобы поток не менялся. Оставить реализацию без изменений и закрепить тестом предположение: Один stack trace на startup объяснит последующие ошибки. Оставить структуру прежней, документировав утверждение: MDCContext гарантирует распределённый trace через сеть без заголовков. Редактировать чувствительные поля, логировать решение один раз на границе и добавить SLO-метрики/спаны для зависимостей. Добавить защитную проверку перед фрагментом, поскольку достаточно увеличить текст каждого сообщения до полной копии request с секретами.