Keep Pydantic out of your Domain Layer

Original Article ↗ Hacker News Discussion ↗

Overall reaction to the article

  • Many find the proposed pattern (Pydantic → dacite → dataclasses) over‑engineered, especially for typical CRUD apps.
  • Critics say the post explains how to separate but not clearly when it’s worth it, or what concrete problems Pydantic in the domain has actually caused.
  • Others defend it as standard DDD/“clean architecture” advice: keep the domain independent of infrastructure and external tools.

Domain vs API models

  • Supporters of separation argue:
    • API types and domain types often need to diverge (security, privacy, performance, usability of API vs internal convenience).
    • Schema‑first or DTO‑based APIs help avoid accidental breaking changes and data leaks (e.g., JSON‑serializing ORM objects directly).
    • Clear domain models make large, multi‑team codebases more predictable and easier to evolve.
  • Skeptics counter:
    • This can quickly lead to armies of near‑duplicate DTOs and mappers, slowing development and making small changes (like adding a column) expensive.
    • In many real‑world Python apps, a single model for IO + domain is “good enough” and simpler to maintain.

Pydantic’s role and performance

  • Some report Pydantic (especially deeply nested models) as a performance bottleneck vs dataclasses, even with validation disabled.
  • Others note v2 improvements and that Python performance still matters at scale (infra cost, latency), despite being a “slow” language.
  • Pro‑separation commenters say Pydantic’s value is at boundaries (runtime validation, parsing) and brings little benefit for internal semantic logic, where plain dataclasses or other structures suffice.

Ecosystem and alternatives

  • Django/DRF users complain that migrations to FastAPI + Pydantic often reduce expressiveness and validation ergonomics compared to DRF serializers.
  • Alternatives mentioned: marshmallow, plain dataclasses, TypedDicts, pyrsistent, SQLModel (with mixed reviews), Protobuf-based models.
  • Some are uneasy about over‑reliance on a third‑party like Pydantic (breaking changes such as .dict → .model_dump); others argue its popularity makes it more reliable than smaller helper libs like dacite.

Typing, validation, and philosophy

  • There’s a parallel debate about Python’s typing culture: static checkers (mypy/pyright) vs runtime validation (“parse, don’t validate” vs validate everywhere).
  • Several note that full separation (DTOs, domain, DB, message schemas) is justified when backward compatibility and multi‑team evolution trump raw development speed.