Thanks for your video! Interesting to see that you place controllers inside of the application layer. From my experience controllers are often placed inside of the presentation layer. Controllers are responsible for handling incoming requests, orchestrating responses, and interacting with use cases or application services. These responsibilities are specific to how the application interacts with the outside world (e.g., HTTP, WebSocket, or any other interface). The application layer, on the other hand, focuses on the core business logic and rules, independent of delivery mechanisms like HTTP or UI. By placing controllers in the presentation layer: - You isolate delivery-specific concerns (e.g., web or API handling) from the core application logic. - Changes to the delivery mechanism (e.g., migrating from REST to GraphQL) don’t impact the application layer. The application layer should define use cases or services that can be reused across multiple interfaces (e.g., CLI, API, scheduled jobs). What's your opinion about this? Thanks
you don't explain value objects and domains services properly. a value object is a set of fields that have common parenting WITHIN an entity. for example in a "Person Entity", which very well would be an aggregate root entity, First Name, Middle Name, and Last name. are a "Name value type" a domain service is ONLY needed if you have a particular Business Transaction that spans Aggregate roots and should be considered carefully for implications. creating transaction across the aggregate root boundary means either distributed transaction or something like saga pattern. sometimes a lot of domain services is a smell that you don't really have your aggregate roots accurate.
You are a great teacher. Excellent stuff ❤
Thanks mate!
Please start a playlist/ course where you build a mock application using Domain-Driven Design
Arguably one of the most straightforward and effective explanations for DDD. I appreciate the excellent content.
Happy that you liked it! 🙂
Probably one the best and simplest explanations for DDD. Thanks for the great content.
Thanks for the feedback! 🙂
I love free education, thank you so much!
excellent explanation for DDD. thank you for sharing this.
Glad you enjoyed it!
Thanks for your video! Interesting to see that you place controllers inside of the application layer. From my experience controllers are often placed inside of the presentation layer. Controllers are responsible for handling incoming requests, orchestrating responses, and interacting with use cases or application services. These responsibilities are specific to how the application interacts with the outside world (e.g., HTTP, WebSocket, or any other interface). The application layer, on the other hand, focuses on the core business logic and rules, independent of delivery mechanisms like HTTP or UI.
By placing controllers in the presentation layer:
- You isolate delivery-specific concerns (e.g., web or API handling) from the core application logic.
- Changes to the delivery mechanism (e.g., migrating from REST to GraphQL) don’t impact the application layer.
The application layer should define use cases or services that can be reused across multiple interfaces (e.g., CLI, API, scheduled jobs).
What's your opinion about this? Thanks
Look into hexogonal architecture, controllers are part of the MVC pattern for frontend which sits outside of domain model (incl. app services)
Thank you so much for this video, one of the best
This is gold! Thank you for sharing this video!
Thank you for the video
Amazing explanation
Best explanation
Thank you so much for your work...
thanks yarr that's what i needed.
Top Class👏👏
So who uses aggregates? I went through the code and none of the repository, services, events or value-object uses it.
HI. great video. What tool do you use for presentation?
Eraser.io 🙂
Excellent! Where is part 2?
This meant to be part 2 I believe:
ua-cam.com/video/l93N4XaQJok/v-deo.html
underrated video!
Controllers are 100% infrastructure. Your application core should never care whether inputs come from an HTTP request or via CLI arguments
Yes, see hexagonal architecture
you don't explain value objects and domains services properly.
a value object is a set of fields that have common parenting WITHIN an entity. for example in a "Person Entity", which very well would be an aggregate root entity, First Name, Middle Name, and Last name. are a "Name value type"
a domain service is ONLY needed if you have a particular Business Transaction that spans Aggregate roots and should be considered carefully for implications. creating transaction across the aggregate root boundary means either distributed transaction or something like saga pattern. sometimes a lot of domain services is a smell that you don't really have your aggregate roots accurate.