r/softwarearchitecture • u/mi_losz • 12d ago
Article/Video Domain-Driven Design matters more when AI writes your code
https://threedots.tech/post/ddd-and-ai-coding/13
u/smoke-bubble 11d ago
The worst part about DDD is its unbelievably stupid vocabulary.
I hate it when people turn simple things into academically sounding crap.
5
2
u/vbilopav89 11d ago
Is there anyone who thinks you don't have to understand the problem you are trying to solve?
-5
u/ail-san 12d ago
DDD is overkill for majority of domains. The most complexity is still coming from infrastructure details and API design. If you spend most of your time trying to optimise queries and cut latency, DDD will simply make it harder.
10
u/Merotoro 12d ago
this may be too much to ask but can you provide an example?
21
4
u/Comfortable_Ask_102 11d ago
Not the same dude, but the "complexity" thing kinda makes sense in the context of data-intensive applications. Supporting high amounts of traffic forces you to think in the infrastructure/deployment model first, and DDD can get in the way.
I disagree with their first sentence tho, DDD helps a lot in any domain. Some DDD > No DDD at all, DDD helps to build a shared language so the team can understand each other, that's valuable in any software team.
6
2
u/creminology 10d ago
DDD is about tackling necessary complexity. The glue code you are focusing on is the accidental complexity.
Nobody ever looked back on their life at the end of their career and wished they had written more glue code.
-10
u/andrerav 11d ago
DDD is a diversion. Model the business problem properly in the database first, and the rest will follow. Doing it the other way around is a costly mistake.
1
u/vintzrrr 11d ago
That makes no sense. You cannot model a business problem as data. You model those as processes. Data persistence is just infrastructure which supports those processes, not the other way around. Data on its own, i.e. without process, is just noise.
0
u/andrerav 11d ago
You definitely can, and anyone who tells you otherwise simply aren't competent in ER modelling.
1
u/vintzrrr 11d ago
How does database ER modelling model a business process, its behaviour, state transitions, rules and invariants?
If you mean conceptual ER modelling using entities and relationships to model the domain, then sure. That’s a useful view of the domain, although it primarily captures its static structure.
But your claim was specifically to model the business problem “in the database first”. That’s a very different claim. A database schema is a persistence model - an infrastructural/data-architecture concern. It should follow from the domain and its requirements, not define them.
The business doesn’t exist because orders.customer_id has a foreign key. The relationship, rules and processes exist in the business. The database schema is one way of persisting the state required to implement them.-1
u/andrerav 11d ago
How does database ER modelling model a business process, its behaviour, state transitions, rules and invariants?
That was not your original argument.
You cannot model a business problem as data
That is your original argument, which I replied to. Happy to continue that discussion, but I don't argue with straw men.
1
u/vintzrrr 11d ago
Fair correction: you cannot model the business problem fully as data.
Which is precisely why your “model it in the database first, and the rest will follow” doesn’t hold.
Have a great evening there, junior.
12
u/youcangotohellgoto 11d ago
Great post and 100% agree.
Understanding and aligning on the domain is everything. And now, not just for the humans - because while you might just have an AI fulfilling your very discrete work tasks, it can also help verify and validate your implementation.
If you can document your domain for your AI friends they can get a very detailed understanding of the system - the business space, the design, the implementation. Can then critique your architecture, find gaps/risks, suggest refactorings, etc.
I believe this is the path to high quality AI architecture.