▲ | NeutralForest 4 days ago | |||||||||||||||||||||||||
What's the motivation for doing this? When does Pydantic in the domain model starts being an issue? | ||||||||||||||||||||||||||
▲ | halfcat 4 days ago | parent [-] | |||||||||||||||||||||||||
When the structure of your team makes it a problem. Conway’s law. If you have one person maintaining a CRUD app, splitting out DTOs and APIs and all of these abstractions are completely not needed. Usually, you don’t even know yet what the right abstraction is, and making a premature wrong abstraction is WAY worse. Building stuff because you might need it later is a massive momentum killer. But at some point when the project has grown (if it grows, which it won’t if you spend all your time making wrong abstractions early on), the API team doesn’t want their stuff broken because someone changed a pydantic model. So you start to need separation, not because it’s great or because it’s “the right way” but because it will collapse if you don’t. It’s the least bad option. | ||||||||||||||||||||||||||
|