This is a nice example of SoC, yet also yields to an anemic domain model when there exists a service layer operating on entities - the changes to which are not encapsulated within the entity (read: aggregate root in the case of a user changing their profile image here). ADMs are okay for CRUD, just as a rich domain model also has it's trade-offs, but I feel it's important to make the distinction clear. Purporting to use DDD yet only focusing on placing code in different directories is not DDD, it's a directory structure.
Lead Developer and Solutions Architect, I specialise in Event Sourcing, DDD and Event Driven systems. PHP and GoLang developer. Enjoys being a smart ass and having a nice whiskey.
Location
Ireland
Education
MSc in Computer Science, Trinity College, Dublin
Work
Lead Developer and Solutions Architect at Contractor
I agree, the above isn't a solid example of DDD, and it should not be viewed as such.
The above code is a contrived example to explain the concept of a clean architecture, so it doesn't feature any of the richness that a real domain model would contain.
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.
This is a nice example of SoC, yet also yields to an anemic domain model when there exists a service layer operating on entities - the changes to which are not encapsulated within the entity (read: aggregate root in the case of a user changing their profile image here). ADMs are okay for CRUD, just as a rich domain model also has it's trade-offs, but I feel it's important to make the distinction clear. Purporting to use DDD yet only focusing on placing code in different directories is not DDD, it's a directory structure.
Hi James,
I agree, the above isn't a solid example of DDD, and it should not be viewed as such.
The above code is a contrived example to explain the concept of a clean architecture, so it doesn't feature any of the richness that a real domain model would contain.