Why is everyone saying we should be doing DRY but we really end up defining the same shit everywhere?

Does separation of concern breach DRY principle?

I have dtos, entities, viewmodels all throughout different layers I have to define. I swear I've changed 8 files just to introduce a new field!!!

If you built a house, you'll built walls.

Some walls will be load bearing and thus not removable.

They're all walls, looking the same, yet some are special as they guarantee safety. Deduplicating walls == bad idea.

DRY and SOLID are principles. They're not a golden lawbook that must be followed word by word, nor a way of guaranteeing success.

Duplication doesn't have to be evil, especially not if intended.

Duplication or redundancy is a very nifty and important tool - used wisely, it can make the difference between "changing more files" vs "rewriting everything".

Redundancy is the compromise between "seperation of concerns" vs "tight coupling".

If you remove every redundancy, logical consequence is that a change of the now sole occurrence will affect the whole application / library / ... .

Which makes the code base unmaintainable long term.

I try not to duplicate. Unless it takes more code to not duplicate. So I try to make code that duplicates less.

I feel you, it’s a downside of OOP, but it’s also a plus since everything is organized according to a set of rules defined at the beginning. If you don’t know what I mean, try doing some functional programming. Regardless, I always just try to leave a codebase better than I found it.

duplicate if it makes more sense to have them separately, than together. e.g. if different teams will be developing them both separately, if in the future it's very likely they'll be getting different feature sets/will have to behave differently/etc.

Look a bit into the future, try to guess what's going to happen with those entities and see what makes more sense in each particular case: DRY or WET.

Default to DRY, unless you anticipate WET being more beneficial

If your application is small enough than you can get away with one or two models. The thing is that the DTO is similar but usually not the same as the have special types/context or some form of mapping going on. In go and I'm sure other languages as well it's common to generate as much as possible so you don't have to do all that manually and make mistakes.

Even so I've found this to be the downfall of DDD. The walls that you put up sometimes separate a single thing over multiple layers introducing multiple concepts that are just about all susceptible to a change. Of course then there are breaking changes in a API you are glad it's only the outer layer/DTO that has to change.

DRY vs WET is about finding the "correct" level of abstraction. If your code is too concrete, you have a lot of duplication; one change will result in a so called "shotgun surgery" (code smell). Having code be too abstract results in cognitive overload; i.e. reading completely DRY code is very slow and difficult to understand (see "enterprise fizzbuzz" on GitHub).

Both principles, DRY and WET, are correct, BUT NOT AT THE TIME: code should be WET first (with two, three maybe even four duplicated and slightly modified implementations [think duplicating a function and only changing the parameters]) and then DRYed out. But only if needed.

There are a couple of additional benefits, but in short: doing it this way, will ensure you always have the actual correct level of abstraction: not too DRY and not too WET.

(Automated tests to ensure correct refactoring should be a given.)