DTOs are one of the big code smells of a code base that does little but will be full of boilerplate. As soon as you see an automapper or a folder of DTOs you know you're in for some serious pain.
On the plus side you also know you can reduce the codebase by about 75%.
It's not that your domain is different, it sounds more like you don't know how to use ORMs. ORMs don't have to manage migrations, they don't have to even write into the database. When dealing with a bad database design, it can be a legitimate tactic to use ORMs in read-only mode and have writes still as hand-rolled SQL. You can do database-first ORMs, as well as code-first, where the database design is king, not the POCO.
> The domain deals with a lot of things that are not in the database.
You can have non-serialized properties. You can even can over-ride serialization/de-serialization of individual properties
> The domain is one of many and deals with just a fraction of what is in the database
You can use different ORMs for different parts of your domain, you could even wrap multiple ORMs in a wrapper repo pattern if you want
> The domain deals with things stored in several databases
As above.
> The database was designed in the 90s and the domain is new
Tons of solutions for this, one easy one is using SQL Views, just ask Claude. The weird thing here is that I've now dealt with this IRL like 5 times and came to the opposite conclusion of you. I found wrapping a bad DB design with an ORM a great first step in fixing it, as the ORM effectively acts as an easy strangler pattern.
> It's not my database so I can't change it
You can still use ORMs, ORMs don't have to manage migrations. Though I feel sorry for you working somewhere you still have a DB guy gatekeeping the database design in 2026.
The point is, every one of your objections are pretty trivially solvable with many mature ORMs, because everyone else had the same problems two decades ago and instead of throwing up their hands and hand-rolling their SQL, the ORM tooling was improved.
The trouble with SOLID is that it's mainly an artifact of old languages and paradigms.
3 of the letters are almost irrelevant in modern code, or barely worth thinking about most of the time.
So what's the value here? Single responsibility?
That kind of thing is now so known that it doesn't really need talking about, like you don't really need to endlessly discuss the database normal forms like people did in the 00s.
Concepts that are worth explaining to beginners, but most code will follow it by default.
Seeing it in job descriptions is more an indicator that a company has an inexperienced lead more than anything else.
Speaking from a UK perspective global warming is now noticeable, hot days are hotter and there's more likely to be a heat wave, and that's changed in the last decade.
I assume Germany is the same, many years ago really is different to today.
Bad architects favour microservices over monoliths.
YAGNI almost always applies to microservices, and the coordination overhead and boilerplate they add introduces immense costs, especially for smaller companies.
This homogenisation of architecture around Netflix size engineering has really cost our industry a lot.
I think a problem here is you're overestimating how hard it is to rewrite something when you have one example of how to do it right. Even in the 2000s, I remember a junior essentially rewriting our entire codebase from old school asp vbscript to .Net in a few months. A 100 or so pages back then.
Your team could have done it pre-AI, but you just thought it was hard so you didn't try.
I remember migrating a code base from MySQL to SQL Server in the 2010s. I thought it would take me weeks, if not months. It took me a couple of days.
Immediately made me sour on the "hot" idea in the 2010s that your data layer should be provider agnostic so you could switch if you needed to. That was never a real thing, it was a made up justification for unnecessary over-engineering, by people who had clearly never tried to port an app from one data source to another. There are other reasons for a clear separation, but switching a few hundred SQL statements is not it.
In reality, mechanical ports are not that hard, you can sit down, put some music on and blitz it in a few days. Programmers just over-estimate how hard they will be.
There's absolutely no way I'd be advising friends or family to run a site vibe coded themself, that's nuts.
This is more a problem of your Mum mismanaging her contractors. She should be threatening hellfire down on this contractor for withholding the admin username + password.
Generating the site with Claude would be a pretty stupid choice for her right now, if she needs something more than a basic info site, word press is still king, but she should be able to do info updates herself.
OTOH, you might be able to ask Claude to do the changes for you.
I think it's the same throughout startup software to be honest. It's just easier to point out when there's clear rules.
Security, GDPR, backups, build pipelines, disaster recovery, most of it will be faked, half-heartedly done once or ignored entirely.
Then there's the more abstract things like scalability, idempotency when integrating with external APIs, error recovery, accessibility, UX, etc.
Almost always that sort of stuff will have been entirely ignored, or there will be a fig leaf over a real mess of misunderstood standards or manual intervention steps.
Startup developers usually have to be generalists as they often wear many hats, so things that need deeper domain knowledge get done to a bare minimum.
That era is already long gone. Those things have been built in Wix for over a decade. And since then, I haven't had any friends or family ask me for a simple site. The low-value work is already automated.
Your comment is valid, but not for the reason you think. What you should be talking about is the grunt work done in our field to non-trivial applications. Adding a search box to a table, or add an extra field to a form, etc.
So you think about a ticket that often might take a few hours, but in badly architected system might take a week, add a field to a class, edit the DB structure (maybe manually, maybe through via an ORM generated migration), add it to DTOs, add a validator, add it to the FE definitions, edit the page layout, etc..
Low value work that until now had to be performed by high-value employees.
With stuff like this, do you honestly not feel that you've probably been tricked and that someone else actually did this?
Don't get me wrong, I think AI can do some surprising things, but with stuff like this, often it just stole the code and the steps without attribution, it didn't figure it out.
There'll probably be a blog post detailing exactly how to do this somewhere and Claude just copied the steps and code.
And worse, Google search would have found it 10 years ago, but Google search today would claim there are no results?
I think incredibly specific stuff like this often won't pass the 'did Claude just steal this?' test when you dig into it.
The greatest trick that javascript ever pulled was to convince the latest generation of programmers that it was fast...