When I started trying to do DDD, I was focused on technical patterns like Repository, Domain Event, etc. Much like "Agile" shops think if they get the processes right, the software will automatically be good; I thought if I used the right patterns, the software would be good. Both of which turn out be patently false.
Your article tells me what I wish I had known about DDD from the start... that it is not about technical patterns (and in fact, I don't believe I use any of them from the book today). It is all about learning the "domain". That's the key to writing good software.
Thank you!
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.
When I started trying to do DDD, I was focused on technical patterns like Repository, Domain Event, etc. Much like "Agile" shops think if they get the processes right, the software will automatically be good; I thought if I used the right patterns, the software would be good. Both of which turn out be patently false.
Your article tells me what I wish I had known about DDD from the start... that it is not about technical patterns (and in fact, I don't believe I use any of them from the book today). It is all about learning the "domain". That's the key to writing good software.
Thank you!