[calebio]

Agreed. Although, sometimes it feels like this is a losing battle. I've worked with too many people who see that level of separation as "unneeded duplication", with constant complaints about having to update a bunch of different layers "just to add a new field.

IMO, at a minimum, you have your API layer model, your internal model, and your database model with a mapping layer at each boundary.

I rarely have problems when I structure it that way, but when working on applications that pass the same model from their API down to their database, or vice-versa, it's always full of the same types of problems that comes with tight coupling.

[macrael]

I think there are certain types of boilerplate that used to be truly onerous that are now much less so because of types. If there are 3 different files that need to be updated to add a file, and forgetting one is only going to error at runtime (maybe even only if you're exercising that new field) that's horrible. But 3 files that require updating where the code won't compile until you've added all three is way way less of a problem.

[tlrobinson]

> But 3 files that require updating where the code won't compile until you've added all three is way way less of a problem.

I think this is only really possible in a relatively small subset of programming languages, even among those with static typing. At a minimum it seems like it would require a type system that didn't allow optional properties (by default) and did distinguish between nullable and non-nullable types.

Unless I'm missing something. Would love to see some examples of this done right. Or at least examples of languages you've done this in.

[macrael]

Optional types can get you for sure. I've been doing this with typescript and it's been alright. Prisma -> my domain model -> ApolloServer

[senorrib]

This is exactly my experience. Glad to see I'm not alone, sad to hear that it's so common out there.