STOP dogmatic Domain Driven Design

The mainstream thought on Domain Driven Design is about Entities, Value Objects, Aggregates, Repositories, Services, Factories... all kinds of technical patterns. Because of this, most don't think they need Domain Driven Design because it's complicated for their domain. Why would you need all that "stuff"? Well maybe you don't! In a large system, modeling your domain, defining boundaries, and how they relate is far more important than concerning yourself with if you're using the Repository pattern correctly.

🔔 Subscribe: @codeopinion

💥 Join this channel to get access to source code & demos!
@codeopinion

🔥 Don't have the JOIN button? Support me on Patreon!
Patreon: codeopinion

📝 Blog: https://codeopinion.com/stop-doing-do...
👋 Twitter: Twitter: codeopinion
✨ LinkedIn: LinkedIn: dcomartin

0:00 Intro
0:38 Technical Pattern Focus
2:53 Context is King
5:41 Resources

https://github.com/ddd-crew/bounded-c...
https://github.com/ddd-crew/aggregate...
https://www.eventstorming.com/

#softwaredesign #domaindrivendesign #softwarearchitecture

• #science_technology
• #domain_driven_design
• #software_architecture
• #software_design
• #cqrs
• #event_sourcing
• #software_architect
• #microservices
• #event_driven_architecture
• #message_queuing
• #microservice_architecture
• #domain_driven_design
• #domain_driven_design_microservices
• #domain_driven_design_bounded_context
• #domain_driven_design_eric_evans
• #domain_driven_design_interview_questions
• #domain_driven_design_book
• #domain_driven_design_microservices_exemple
• #domain_driven_design_boook
• #bounded_context