DDD applies to software, both backend and frontend
It is about modelling the problem space in the solution space
It is about finding context boundaries using linguistic and business differences between contexts
It is also about being able to model each context using its own model with its own language
I totally agree that splitting files per type makes little sense. Developers deliver functionality and working on a certain feature should not require adding or changing files in twenty folders.
Concerning the infrastructure and dependencies, it, in fact, has little to do with DDD. Clean Architecture, ports and adapters, onion architecture and, in fact, software engineering is all about finding the right level of abstraction, building loosely-coupled and highly cohesive components.
Thank you for your contribution. It made me realize that I should emphasize more on determining context boundaries. That's another thing I like about DDD, the fact that it prioritizes using a set of language that translate business terms and complex ideas instead of overly technical language.
I especially like this quote I saw at Martin Fowler's website: "Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design."
Your last paragraph was perfect.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Good content, but I feel I must add something.
I totally agree that splitting files per type makes little sense. Developers deliver functionality and working on a certain feature should not require adding or changing files in twenty folders.
Concerning the infrastructure and dependencies, it, in fact, has little to do with DDD. Clean Architecture, ports and adapters, onion architecture and, in fact, software engineering is all about finding the right level of abstraction, building loosely-coupled and highly cohesive components.
Thank you for your contribution. It made me realize that I should emphasize more on determining context boundaries. That's another thing I like about DDD, the fact that it prioritizes using a set of language that translate business terms and complex ideas instead of overly technical language.
I especially like this quote I saw at Martin Fowler's website: "Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design."
Your last paragraph was perfect.