Accessors are usually defended as legitimate at boundaries - DTOs, wire formats, persistence. Compare how Go's encoding/json, Rust's serde and reflective serializers such as Jackson or System.Text.Json get at an object's state, and what each implies for whether the domain type and the wire type can be the same type.

## Why the boundary is the interesting case Everyone agrees a domain object should protect its rules, and everyone agrees data crossing a wire is just data. The argument is about whether those must be different *types*. That is not a matter of taste - it is decided largely by a mechanical question: how does your serializer obtain the values it writes, and how does the deserializer put them back? ## Three mechanisms **Reflection constrained by visibility - Go.** `encoding/json` reflects over a struct but can only read exported (capitalised) fields. An unexported field is not an error and not a warning; it simply does not appear in the output. The consequence is severe and clarifying: to serialize state you must make it public to every package in your program. So in Go the choice "one type for domain and wire" costs you all field-level encapsulation, and idiomatic Go therefore defines a separate wire struct with `json:` tags and writes explicit mapping functions. The boilerplate buys a real property - the wire contract is a distinct type that can evolve on its own schedule, and a domain rename cannot silently change the protocol. **Compile-time code generation - Rust.** `#[derive(Serialize, Deserialize)]` is a procedural macro expanded in the type's own module, so the generated code has ordinary access to private fields. You can serialize a fully encapsulated struct with no visibility change. That is strictly more capable, and it moves the hazard rather than removing it: nothing now stands between your internal field names and the bytes on the wire, so renaming a private field is a silent protocol break. Mitigations exist - `#[serde(rename)]`, `rename_all`, `default`, `skip` - and they are effectively a schema declaration, at which point you have re-created the DTO as annotations rather than as a type. Which is fine, as long as you know that is what you did. The same story holds for any generated-codec approach: Swift's `Codable` with `CodingKeys`, Kotlin's `kotlinx.serialization` plugin. **Unconstrained reflection - Jackson, System.Text.Json.** JVM and .NET serializers can read and write non-public members given configuration, and historically the path of least resistance was the bean convention: a public no-arg constructor plus a setter per field. That combination is exactly an object with no invariants, because it must be constructible in an empty state and mutable into any state. This is the concrete origin of "our ORM and our JSON library forced us into data bags" - and it is no longer true. Jackson supports constructor binding via `@JsonCreator`, works with Java records, and has a Kotlin module for data classes; System.Text.Json binds to parameterised constructors and supports `init`-only setters and `required` members. The framework constraint that produced a generation of anemic models has been removed, and codebases that still cite it are citing history. **The single-type extreme - Python.** With pydantic or dataclasses the model class *is* the parsing, validation and wire type, and this is idiomatic rather than a compromise. The cost is a dependency direction: the framework's base class becomes a dependency of your core types, and the validation vocabulary of the boundary leaks into the domain. ## Drawing the line Two forces decide whether to keep one type or two: 1. **Can the serializer see private state?** If not (Go), one type means no encapsulation, so two types is nearly forced. If yes (serde, Jackson, System.Text.Json), one type is technically possible. 2. **Must the wire shape be able to differ from the field shape?** Independent versioning, a public API contract you cannot break, field names that must stay stable across an internal refactor, or fields that must never leave the process - each of these argues for a second type regardless of language, and each of them is a reason that has nothing to do with encapsulation dogma. When you do keep one type, the discipline that keeps it honest is that the accessors exist for the boundary and nothing else: they are read at the edge, they are not the way the rest of the system asks the object questions, and no business decision is made from them elsewhere. When an accessor added "for the serializer" starts appearing in a service that computes something from it, the boundary has leaked into the core, and that is the point where splitting the type stops being ceremony and starts paying. ## The reverse direction matters too Deserialization is where invariants die. If the framework can construct your type field by field, it can construct states your constructor would have rejected. Constructor or factory binding, validation invoked after binding, and immutable targets are the three ways to keep the guarantee - and their availability, again, is a language and library fact: records and `@JsonCreator` on the JVM, `required`/`init` in C#, `#[serde(try_from)]` in Rust, validators in pydantic, and explicit hand-written mapping in Go.