Reddit reviews Implementing Domain-Driven Design
We found 10 Reddit comments about Implementing Domain-Driven Design. Here are the top ones, ranked by their Reddit score.
Addison-Wesley Professional
I currently work with the Axon Framework. The community isn't that great, but the inventor is fantastic. He's always willing to help (at least it seems that way). I would suggest looking around the internet at things such as CQRS, Event Sourcing, and DDD (Domain Driven Design).
Since you asked for resources I would suggest Vaughn Vernon. Also, my coworker has a giant list of resources, here you go.
DDD Stuff:
Axon Stuff:
>would that mean, technical, that you have multiple Order classes based on context?
Yes. Generally you have a "source" domain where the order originates and the order in other domains generally build their order off of the original order one form the "source" domain.
>If so, do they have their own DAL or do they get mapped differently?
Similar to microservices, its recommended that each domain has it's own persistence mechanism. If you've got really big contexts, especially if they have multiple Order types, then you're probably doing it wrong. The ultimate idea is that an Order in each domain is allowed to evolve independently from any other domain.
>I haven't found a "from 0 to done" example yet
From my experience that's kinda hard, just because there's a lot that exists outside the code with DDD. You need to have the documentation and knowledge from the subject matter expert to really understand why certain things are structured the way they are and why certain terms might be used over others.
As far as resources go, the obvious answer is to go directly to Eric Evan's book, but I also feel that's a lot to chew and digest if you're just getting into the topic. My recommendation is to actually start with Vaughn Vernon's Domain Driven Design Distilled, as it gives a higher level overview and description of the concepts of DDD rather than diving into the deep end like Eric's book. From there, I'd either go to Eric's book or to Vaughn's other book, Implementing DDD. Once you get a lot of the concepts, I've found that Patterns, Principles, and Practices of DDD is a good book to get a handle on the code, architecture, and infrastructure implications of DDD.
I recommend learning about Domain Models (Crafting Wicked Domain Models by Jimmy Bogard is highly recommended) and Domain-Driven Design (this Pluralsight course is the best introduction in my opinion).
Though the sample code in those videos is in C#, it should be straightforward to translate it into PHP. Watching those videos and reading books like Implementing Domain-Driven Design have taken my coding to a whole new level.
Read Implementing Domain-Driven Design . Customers and orders are in different bounded contexts, i.e. a customer object should not load all associated orders and vice versa.
The few comments in here aren't explaining WHY the interviewer said "very 90s". Obviously, "very 90s" is over-exaggerated... "very 2000s" is a bit more accurate.
What you've got is a "typical" layered architecture, which is considered a bit out-dated these days. There's a couple major reasons people move away from that architecture now.
For a quick look at an alternative project structure, you can check out Onion Architecture, which moves business logic to the application core on CodeProject (this is similar to ports & adapters)
For more in-depth, look into Domain Driven Design (DDD). Many an architect, including myself, would suggest Eric Evans' book on the topic.
For a more recent DDD book, see Vaughn Vernon's Implementing Domain Driven Design.
No. And every fucking article about DDD in some php Framework should be hanged over running water then burnt and theirs ashes spread around the solar system.
Frameworks are just details in DDD. Your app may even be just a detail. What is your company making? What is your Core Domain on which you should assign your top people and resources? What is on the periphery and can be using software from outside?
DDD is more a way to organize your company and decide what to focus on. The architecture you get should come from analysing your domains, your contexts and change when your common knowledge about those get better.
Instead of reading these kind of blogs and applying cargo-cult php DDD read the red book.
He used the word "bounded context" using its meaning from Domain-Driven Design approach https://martinfowler.com/bliki/BoundedContext.html and that's what triggered Vernon who is the author of 2 books on this topic https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577 and https://www.amazon.com/Domain-Driven-Design-Distilled-Vaughn-Vernon/dp/0134434420/ . That's what makes this whole conversation funny.
No, no, no. The principle is great, but that book is bonkers.
You want the Vaughn books if you're doing DDD:
The bigger book: https://www.amazon.co.uk/dp/0321834577/ref=pd_lpo_sbs_dp_ss_1?pf_rd_p=569136327&pf_rd_s=lpo-top-stripe&pf_rd_t=201&pf_rd_i=0321125215&pf_rd_m=A3P5ROKL5A1OLE&pf_rd_r=83Y7X80HPERQ5AMCEXGG
The shorter book: https://www.amazon.co.uk/Domain-Driven-Design-Distilled-Vaughn-Vernon/dp/0134434420/ref=pd_sim_14_2?_encoding=UTF8&psc=1&refRID=M5QXQ063YDX0E768HE3S
Source: read all of them tried getting traction across multiple teams citing them as sources, and the Evans book is almost intractable to most. Vaughn also at least starts talking about CQRS in a reasonable way, and introduces it using DDD.
Well of course. The new hot thing needs to clear the space for itself: DDD, CQRS, Event Sourcing. This approach cannot be done Agile way because it requires top-down architecture design.
New books need to be sold. New consultants need to sell their services.
Endless circle of life.
Implementing DDD from Vernon is a must-read after Evans:
https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577
It is not exactly focused on microservices. However, the DDD conception "Bounded context" is the key point for microservices.