I have a strong opinion that your core domain models should never be directly polluted by third-party API schemas. It is a fundamental architectural sin that I see constantly in codebases: developers mapping a third-party JSON response straight into their internal entities or passing API DTOs all the way through the business logic layer. An external API is a volatile, foreign boundary. When you let its data structures leak into your domain, you are effectively allowing an external dependency to dictate the architecture of your own application, turning your system into a passive puppet rather than a robust, independent service.
The moment a third-party changes their endpoint schema, your domain logic breaks, and you are forced to scatter mapping fixes across your entire codebase. This violates the Dependency Inversion Principle and creates what I call "architectural leakage." Instead, you must treat the API integration as a strict boundary, implementing a translation layer (or Anti-Corruption Layer) right at the point of ingress. Transform the external data into your own canonical models immediately. The outside world should only ever speak to your adapters, never to your core domain; if you keep your API integrations strictly isolated at the edges, your architecture remains resilient, testable, and entirely in control of its own evolution.
Top comments (0)