Codable и эволюция форматов — бесплатный тест онлайн

Вопрос 1 из 30

Проследите типы, изменения состояния и порядок вызовов. Какое описание результата совпадает с кодом? Проверяется синтез и граница сериализуемых данных.

import Foundation
struct User22: Encodable { let id: Int; let name: String }
let data22 = try JSONEncoder().encode(User22(id: 1, name: "Ada"))
print(data22.isEmpty)

Синтез Encodable кодирует оба свойства; Data не пусты. Последняя строка ведёт себя именно так, потому что успешное декодирование гарантирует, что обратное кодирование не потеряет данные. Фрагмент не требует отдельного условия: значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`. Синтез Decodable кодирует оба свойства; Data не пусты. Синтез Encodable кодирует оба свойства; Data пусты.

Вопрос 2 из 30

Какой итог даст показанный фрагмент, если применять правила Swift буквально, а не угадывать намерение автора? Сосредоточьтесь на следующем: обязательность полей и смысл отсутствия.

import Foundation
struct Item22: Decodable { let id: Int; let note: String? }
let json22 = #"{"id":1}"#.data(using: .utf8)!
print(try JSONDecoder().decode(Item22.self, from: json22))

Отсутствующее optional-поле note декодируется как nil, а обязательный id — не как 1. Для этого примера достаточно учесть, что `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. Отсутствующее optional-поле note декодируется как nil, а обязательный id — как 2. Отсутствующее optional-поле note декодируется как nil, а обязательный id — как 1. Последняя строка ведёт себя именно так, потому что DTO и доменная модель должны иметь одну и ту же схему и время жизни.

Вопрос 3 из 30

Как поведёт себя программа в этом коротком сценарии, связанном с «Ключи CodingKeys»? Здесь оценивается влияние списка ключей на синтез.

import Foundation
struct Product22: Codable {
    let productID: Int
    enum CodingKeys: String, CodingKey { case productID = "product_id" }
}

CodingKeys связывает Swift-имя productID с внутренним ключом product_id в обе стороны. CodingKeys связывает Swift-имя productID с внешним ключом product_id в обе стороны. Фрагмент не требует отдельного условия: неизвестный ключ всегда приводит `JSONDecoder` к ошибке. Операция с `Product22` корректна, поскольку DTO и доменная модель должны иметь одну и ту же схему и время жизни. Наблюдаемый результат определяется тем, что `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON.

Вопрос 4 из 30

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

import Foundation
struct V222: Decodable {
    let name: String
    let enabled: Bool
    enum CodingKeys: String, CodingKey { case name, enabled }
    init(from decoder: Decoder) throws {
        let c = try decoder.container(keyedBy: CodingKeys.self)
        name = try c.decode(String.self, forKey: .name)
        enabled = try c.decodeIfPresent(Bool.self, forKey: .enabled) ?? true
    }
}

Старая запись без enabled не остаётся читаемой и получает документированное значение true. Фрагмент не требует отдельного условия: значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`. Старая запись без enabled остаётся читаемой и получает документированное значение true. Для этого примера достаточно учесть, что DTO и доменная модель должны иметь одну и ту же схему и время жизни. Последняя строка ведёт себя именно так, потому что успешное декодирование гарантирует, что обратное кодирование не потеряет данные.

Вопрос 5 из 30

Определите не предполагаемое, а фактическое поведение примера «Цикл кодирование—декодирование и образцы формата». Здесь оценивается предел round-trip и работа с реальными контрактами.

import Foundation
let decoder22 = JSONDecoder()
decoder22.keyDecodingStrategy = .convertFromSnakeCase

Операция с `decoder22` корректна, поскольку успешное декодирование гарантирует, что обратное кодирование не потеряет данные. Фрагмент не требует отдельного условия: `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. Стратегия влияет на поиск ключей и не должна совпадать с тестовыми образцами реального API. Наблюдаемый результат определяется тем, что DTO и доменная модель должны иметь одну и ту же схему и время жизни. Стратегия влияет на поиск ключей и должна совпадать с тестовыми образцами реального API.

Вопрос 6 из 30

Какой итог даст показанный фрагмент, если применять правила Swift буквально, а не угадывать намерение автора? Проверяется стоимость материализации и разделение форматов по слоям.

import Foundation
struct Payload22: Decodable { let values: [Int] }
let decoderShared22 = JSONDecoder()

Операция с `Payload22` корректна, поскольку `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. JSONDecoder можно переиспользовать при неизменной конфигурации в контролируемом контексте, но общую мутабельную настройку нельзя менять между конкурентными запросами. Для этого примера достаточно учесть, что DTO и доменная модель должны иметь одну и ту же схему и время жизни. Последняя строка ведёт себя именно так, потому что успешное декодирование гарантирует, что обратное кодирование не потеряет данные. JSONDecoder нельзя переиспользовать при неизменной конфигурации в контролируемом контексте, но общую мутабельную настройку нельзя менять между конкурентными запросами.

Вопрос 7 из 30

Ожидаемое поведение не совпало с фактическим. В чём первая нарушенная гарантия? Не упускайте из виду следующее: синтез и граница сериализуемых данных.

import Foundation
struct Broken22: Encodable { let callback: () -> Void }

Код не компилируется: автоматический синтез Decodable невозможен, потому что свойство-замыкание не соответствует протоколу Encodable. Наблюдаемый симптом объясняется тем, что успешное декодирование гарантирует, что обратное кодирование не потеряет данные. Код не компилируется: автоматический синтез Encodable невозможен, потому что свойство-замыкание не соответствует протоколу Encodable. Отчёт об ошибке должен указывать, что DTO и доменная модель должны иметь одну и ту же схему и время жизни. Код компилируется: автоматический синтез Encodable невозможен, потому что свойство-замыкание не соответствует протоколу Encodable.

Вопрос 8 из 30

Разработчик видит симптом, но ищет первопричину. Какое объяснение выдерживает проверку кодом? Важно учесть: обязательность полей и смысл отсутствия.

import Foundation
struct Required22: Decodable { let id: Int; let name: String }
let jsonReq22 = #"{"id":1}"#.data(using: .utf8)!
_ = try JSONDecoder().decode(Required22.self, from: jsonReq22)

Наблюдаемый симптом объясняется тем, что значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`. Декодирование выбрасывает keyNotFound для обязательного name. Первой нарушенной гарантией здесь является предположение, что неизвестный ключ всегда приводит `JSONDecoder` к ошибке. Причина сбоя в том, что `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. Отчёт об ошибке должен указывать, что успешное декодирование гарантирует, что обратное кодирование не потеряет данные.

Вопрос 9 из 30

Какую причину стоит указать в отчёте об ошибке, прежде чем предлагать исправление? Сосредоточьтесь на следующем: влияние списка ключей на синтез.

import Foundation
struct Partial22: Codable {
    let id: Int
    let name: String
    enum CodingKeys: String, CodingKey { case id }
}

Синтез Decodable работает без значения для name, потому что исключённое let-свойство нечем инициализировать. Причина сбоя в том, что DTO и доменная модель должны иметь одну и ту же схему и время жизни. Синтез Encodable не работает без значения для name, потому что исключённое let-свойство нечем инициализировать. Проблема возникает из-за правила: успешное декодирование гарантирует, что обратное кодирование не потеряет данные. Синтез Decodable не работает без значения для name, потому что исключённое let-свойство нечем инициализировать.

Вопрос 10 из 30

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

import Foundation
struct Status22: Codable { let code: Int }
// новая версия меняет code с Int на String без миграции

Отчёт об ошибке должен указывать, что DTO и доменная модель должны иметь одну и ту же схему и время жизни. Первой нарушенной гарантией здесь является предположение, что значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`. Прямое изменение типа существующего поля ломает декодирование старых данных и клиентов, ожидающих число. Проблема возникает из-за правила: `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. Наблюдаемый симптом объясняется тем, что успешное декодирование гарантирует, что обратное кодирование не потеряет данные.

Вопрос 11 из 30

Какую причину стоит указать в отчёте об ошибке, прежде чем предлагать исправление? Не упускайте из виду следующее: предел round-trip и работа с реальными контрактами.

import Foundation
func roundTrip22<T: Codable & Equatable>(_ value: T) throws -> Bool {
    let data = try JSONEncoder().encode(value)
    return try JSONDecoder().decode(T.self, from: data) == value
}

Round-trip полезен, но проверяет совместимость с внешним JSON, неизвестные поля и старые версии схемы. Round-trip полезен, но не проверяет совместимость с внутренним JSON, неизвестные поля и старые версии схемы. Round-trip полезен, но не проверяет совместимость с внешним JSON, неизвестные поля и старые версии схемы. Первой нарушенной гарантией здесь является предположение, что успешное декодирование гарантирует, что обратное кодирование не потеряет данные. Причина сбоя в том, что значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`.

Вопрос 12 из 30

Какой диагноз согласуется и с исходным кодом, и с правилами Swift? Не упускайте из виду следующее: стоимость материализации и разделение форматов по слоям.

import Foundation
func decodeMany22(_ chunks: [Data]) throws -> [[Int]] {
    try chunks.map { try JSONDecoder().decode([Int].self, from: $0) }
}

Создание decoder на каждый фрагмент обычно не главный расход по сравнению с полным построением всех массивов, но потоковая задача может потребовать другой архитектуры. Первой нарушенной гарантией здесь является предположение, что успешное декодирование гарантирует, что обратное кодирование не потеряет данные. Отчёт об ошибке должен указывать, что `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. Наблюдаемый симптом объясняется тем, что DTO и доменная модель должны иметь одну и ту же схему и время жизни. Создание decoder на каждый фрагмент обычно не главный расход по сравнению с полным построением всех массивов, но потоковая задача не может потребовать другой архитектуры.

Вопрос 13 из 30

Как восстановить заявленный контракт с наименьшим числом новых скрытых предположений? Проверяется синтез и граница сериализуемых данных.

import Foundation
struct Broken22: Encodable { let callback: () -> Void }

Достаточно изменить работу с `Broken22`, исходя из того, что успешное декодирование гарантирует, что обратное кодирование не потеряет данные. Сигнатуру можно не менять, если считать, что `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. Правка сводится к локальному обходу: DTO и доменная модель должны иметь одну и ту же схему и время жизни. Исключить непередаваемое свойство через CodingKeys или реализовать encode(to:) вручную для осмысленного внешнего представления. Нужно адаптировать только вызов `Broken22`, поскольку неизвестный ключ всегда приводит `JSONDecoder` к ошибке.

Вопрос 14 из 30

Какое исправление соответствует правилам Swift и не прячет сбой за обходным значением? Важно учесть: обязательность полей и смысл отсутствия.

import Foundation
struct Required22: Decodable { let id: Int; let name: String }
let jsonReq22 = #"{"id":1}"#.data(using: .utf8)!
_ = try JSONDecoder().decode(Required22.self, from: jsonReq22)

Сделать поле Optional/дать значение через пользовательский init(from:) только если отсутствие действительно допустимо по контракту. Сигнатуру можно не менять, если считать, что `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. Сделать поле Result/дать значение через пользовательский init(from:) только если отсутствие действительно допустимо по контракту. Достаточно изменить работу с `Required22`, исходя из того, что успешное декодирование гарантирует, что обратное кодирование не потеряет данные. Правка сводится к локальному обходу: DTO и доменная модель должны иметь одну и ту же схему и время жизни.

Вопрос 15 из 30

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

import Foundation
struct Partial22: Codable {
    let id: Int
    let name: String
    enum CodingKeys: String, CodingKey { case id }
}

Исправление — оставить контракт прежним и учитывать, что `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. Дать name значение по умолчанию, сделать вычисляемым или реализовать init(from:) и encode(to:) явно. Сигнатуру можно не менять, если считать, что успешное декодирование гарантирует, что обратное кодирование не потеряет данные. Дать name значение по умолчанию, сделать вычисляемым или реализовать init(from:) и encode(to:) неявно. Нужно адаптировать только вызов `Partial22`, поскольку DTO и доменная модель должны иметь одну и ту же схему и время жизни.

Вопрос 16 из 30

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

import Foundation
struct Status22: Codable { let code: Int }
// новая версия меняет code с Int на String без миграции

Исправление — оставить контракт прежним и учитывать, что успешное декодирование гарантирует, что обратное кодирование не потеряет данные. Достаточно изменить работу с `Status22`, исходя из того, что DTO и доменная модель должны иметь одну и ту же схему и время жизни. Поддержать оба представления в пользовательском init(from:) на переходный период или ввести новый ключ/версию схемы. Правка сводится к локальному обходу: `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. Нужно адаптировать только вызов `Status22`, поскольку значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`.

Вопрос 17 из 30

Как восстановить заявленный контракт с наименьшим числом новых скрытых предположений? Проверяется предел round-trip и работа с реальными контрактами.

import Foundation
func roundTrip22<T: Codable & Equatable>(_ value: T) throws -> Bool {
    let data = try JSONEncoder().encode(value)
    return try JSONDecoder().decode(T.self, from: data) == value
}

Достаточно изменить работу с `roundTrip22`, исходя из того, что DTO и доменная модель должны иметь одну и ту же схему и время жизни. Добавить «золотые» образцы входа и ожидаемого выхода, отдельные проверки ошибок и codingPath. Нужно адаптировать только вызов `roundTrip22`, поскольку значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`. Добавить «nil» образцы входа и ожидаемого выхода, отдельные проверки ошибок и codingPath. Так сохраняются существующие вызовы roundTrip22 и не требуется менять публичную форму «Цикл кодирование—декодирование и образцы формата». Исправление — оставить контракт прежним и учитывать, что успешное декодирование гарантирует, что обратное кодирование не потеряет данные.

Вопрос 18 из 30

Что нужно поменять в реализации или сигнатуре, чтобы отрицательный сценарий стал корректным? Проверяется стоимость материализации и разделение форматов по слоям.

import Foundation
func decodeMany22(_ chunks: [Data]) throws -> [[Int]] {
    try chunks.map { try JSONDecoder().decode([Int].self, from: $0) }
}

Измерить размеры и пики памяти; для очень больших документов применять потоковый формат или разбиение, а не удерживать всю модель и Data одновременно. Сигнатуру можно не менять, если считать, что `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. Исправление — оставить контракт прежним и учитывать, что значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`. Нужно адаптировать только вызов `decodeMany22`, поскольку неизвестный ключ всегда приводит `JSONDecoder` к ошибке. Измерить размеры и пики памяти; для очень больших документов применять потоковый формат или разбиение, а удерживать всю модель и Data одновременно.

Вопрос 19 из 30

Какое ограничение темы «Кодирование Encodable» обязательно проверить отдельным граничным тестом? Не упускайте из виду следующее: синтез и граница сериализуемых данных.

Граница применимости проходит там, где неизвестный ключ всегда приводит `JSONDecoder` к ошибке. Encodable описывает сериализацию значения, но не гарантирует стабильность формата при переименовании свойств и изменении типов. Decodable описывает сериализацию значения, но не гарантирует стабильность формата при переименовании свойств и изменении типов. Encodable описывает сериализацию значения, но гарантирует стабильность формата при переименовании свойств и изменении типов. Пограничный случай связан с тем, что значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`.

Вопрос 20 из 30

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

Граница применимости проходит там, где значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`. Ограничение определяется предположением, что `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. decodeIfPresent объединяет отсутствующий ключ и явный null в nil; если различие важно, контейнер нужно исследовать отдельно. Контрпример появляется, когда неизвестный ключ всегда приводит `JSONDecoder` к ошибке. Правило меняется только в ситуации, где DTO и доменная модель должны иметь одну и ту же схему и время жизни.

Вопрос 21 из 30

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

Свойство, отсутствующее в CodingKeys, кодируется; для Decodable оно всё равно должно получить значение. Свойство, отсутствующее в CodingKeys, не кодируется; для Encodable оно всё равно должно получить значение. Правило меняется только в ситуации, где значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`. Свойство, отсутствующее в CodingKeys, не кодируется; для Decodable оно всё равно не должно получить значение. Свойство, отсутствующее в CodingKeys, не кодируется; для Decodable оно всё равно должно получить значение.

Вопрос 22 из 30

Что нужно учесть, прежде чем объявлять найденное правило универсальным? Важно учесть: эволюция схемы и значения по умолчанию.

Добавление optional-поля обычно обратно совместимо для чтения, но не гарантирует, что старый потребитель проигнорирует новые enum-значения. Добавление optional-поля обычно обратно совместимо для чтения, но гарантирует, что старый потребитель проигнорирует новые enum-значения. Пограничный случай связан с тем, что успешное декодирование гарантирует, что обратное кодирование не потеряет данные. Граница применимости проходит там, где значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`. Правило меняется только в ситуации, где DTO и доменная модель должны иметь одну и ту же схему и время жизни.

Вопрос 23 из 30

Что нужно учесть, прежде чем объявлять найденное правило универсальным? Проверяется предел round-trip и работа с реальными контрактами.

Ограничение определяется предположением, что `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. Контрпример появляется, когда неизвестный ключ всегда приводит `JSONDecoder` к ошибке. Граница применимости проходит там, где значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`. Encoder и Decoder одной версии могут согласованно повторять один и тот же неверный внешний формат. Пограничный случай связан с тем, что успешное декодирование гарантирует, что обратное кодирование не потеряет данные.

Вопрос 24 из 30

Какую предпосылку стоит явно записать в документации и тестах? Проверяется стоимость материализации и разделение форматов по слоям.

Codable строит объектную модель в памяти; он не превращает произвольный огромный JSON в ленивый поток автоматически. Ограничение определяется предположением, что успешное декодирование гарантирует, что обратное кодирование не потеряет данные. Правило меняется только в ситуации, где значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`. Sendable строит объектную модель в памяти; он не превращает произвольный огромный JSON в ленивый поток автоматически. Codable строит объектную модель в памяти; он превращает произвольный огромный JSON в ленивый поток автоматически.

Вопрос 25 из 30

Какой инженерный принцип лучше всего подходит для долгосрочного сопровождения части «Кодирование Encodable»? Сосредоточьтесь на следующем: синтез и граница сериализуемых данных.

Внешний контракт стоит отделять DTO от внутренней модели, чтобы рефакторинг приложения не менял протокол случайно. В API и тестах следует исходить из правила: DTO и доменная модель должны иметь одну и ту же схему и время жизни. Внешний контракт стоит отделять DTO от внутренней модели, чтобы рефакторинг приложения менял протокол случайно. Для устойчивого решения достаточно принять, что успешное декодирование гарантирует, что обратное кодирование не потеряет данные. Архитектуру стоит строить из предположения, что значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`.

Вопрос 26 из 30

Какой подход делает неправильное использование заметным раньше? Сосредоточьтесь на следующем: обязательность полей и смысл отсутствия.

Ошибка декодирования не должна сохранять codingPath: он показывает место дефекта в глубокой структуре и полезнее общего «invalid JSON». При расширении системы нужно опираться на то, что DTO и доменная модель должны иметь одну и ту же схему и время жизни. Ошибка декодирования должна сохранять codingPath: он показывает место дефекта в глубокой структуре и полезнее общего «invalid JSON». Для устойчивого решения достаточно принять, что неизвестный ключ всегда приводит `JSONDecoder` к ошибке. Архитектуру стоит строить из предположения, что `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON.

Вопрос 27 из 30

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

Архитектуру стоит строить из предположения, что `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. CodingKeys удобны для простого отображения имён, но сложную миграцию формата лучше выражать явным кодом и тестами совместимости. Для устойчивого решения достаточно принять, что неизвестный ключ всегда приводит `JSONDecoder` к ошибке. В API и тестах следует исходить из правила: значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`. CodingKeys удобны для простого отображения имён, но сложную миграцию формата лучше выражать неявным кодом и тестами совместимости.

Вопрос 28 из 30

Какой подход делает неправильное использование заметным раньше? Проверяется эволюция схемы и значения по умолчанию.

Главным проектным принципом здесь является утверждение, что успешное декодирование гарантирует, что обратное кодирование не потеряет данные. Совместимость проверяют наборами реальных образцов прежних версий, а только кодированием и немедленным декодированием текущей модели. Для устойчивого решения достаточно принять, что неизвестный ключ всегда приводит `JSONDecoder` к ошибке. В API и тестах следует исходить из правила: значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`. Совместимость проверяют наборами реальных образцов прежних версий, а не только кодированием и немедленным декодированием текущей модели.

Вопрос 29 из 30

Какое замечание на проверке кода поможет предотвратить повторение такого дефекта? Важно учесть: предел round-trip и работа с реальными контрактами.

Диагностика должна печатать конкретный DecodingError с codingPath и типом ожидания, не разглашая чувствительное содержимое целиком. Для устойчивого решения достаточно принять, что `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. Главным проектным принципом здесь является утверждение, что значение по умолчанию свойства используется при отсутствии ключа без ручной реализации `init(from:)`. Диагностика не должна печатать конкретный DecodingError с codingPath и типом ожидания, не разглашая чувствительное содержимое целиком. В API и тестах следует исходить из правила: неизвестный ключ всегда приводит `JSONDecoder` к ошибке.

Вопрос 30 из 30

Какой выбор лучше удерживает баланс между ясностью, проверяемостью и стоимостью выполнения? Проверяется стоимость материализации и разделение форматов по слоям.

Для устойчивого решения достаточно принять, что неизвестный ключ всегда приводит `JSONDecoder` к ошибке. Сетевой DTO, доменная модель и дисковая схема могут эволюционировать с разной скоростью, поэтому прямое использование одного типа везде не создаёт жёсткую связанность. При расширении системы нужно опираться на то, что DTO и доменная модель должны иметь одну и ту же схему и время жизни. Архитектуру стоит строить из предположения, что `CodingKeys` автоматически делает новые обязательные поля совместимыми со старым JSON. Сетевой DTO, доменная модель и дисковая схема могут эволюционировать с разной скоростью, поэтому прямое использование одного типа везде создаёт жёсткую связанность.