DEV Community

Discussion on: Domain-driven Design (DDD): File Structure

Collapse
alexeyzimarev profile image
Alexey Zimarev

Good content, but I feel I must add something.

  • DDD is not an architecture
  • 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.

Collapse
stevescruz profile image
Steve Cruz Author

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.