mdwheele/proposal.md

## proposal.md

      
    Raw
  

              proposal.md
            
          
    Edit: A bit of context as more than expected are happening upon the gist.

This is in response to a conversation between a few engineers I consider experts in their respective fields:

Jeffrey Way (of Laracasts) as a technical educator aiming to investigate exposing newcomers to DDD in an easier-to-digest/grasp way.
Konstantine Kudryashov (Behat, phpSpec, Inviqa) as a BDD consultant
Mathias Verraes (dddinphp.org, http://verraes.net/) as a significant DDD resource and independent consultant.

Additional context can be sought reading backwards from https://twitter.com/mdwheele/status/527233999744557056. The stream is a bit broken, but the general gist/context is there.
This stuff is hard to put into 140 characters and I urge folks interested in advanced topics like this to reach out; identify experts in the topic areas and communicate with them. Find communities around these topics and get involved. Learning is hard work and it takes time, practice and patience. We can only hope that educators utilize their expertise in attempting to bring these advanced topics closer, but in the meantime... let's get to it! 😄
Original Post:


Your brain is a muscle of sorts; no different than any other in the body.


I cannot lift 400kg and no matter how much up-front training I am given in my current state, I will not achieve lifting 400kg today, tomorrow, or next year.


I can, over time, train-up through different exercises the ability to achieve that goal, but it takes resource investment which eventually manifest as muscle fibers of appropriate physical organization.


A trainer can instruct me on a personalized efficiency-optimized path towards a specific goal, but the trainer isn't going to simply give me what works for them at the current time. And what works for me may not work for another person in the world. The trainer will break a pathway down into a set of regimented simpler exercises that lead me on the path to success. The trainer can do this because he has achieved mastery in physical training and as such, I do not NEED to know why I'm being asked to do leg-extensions; I just trust.


The trainer understands that each exercise is hitting the right muscle groups that will allow me to one day achieve my 400kg lifting goals.


Tying this back to attempting to distill something like DDD into a technical resource meant to "train" / transfer knowledge to an arbitrary audience:


It can be difficult for a newcomer to approach something like Domain-Driven Design and achieve an applicable skillset to engineer a solution based on the blue book alone. Reading the blue-book first is like trying to understand a college-education in fitness (in 300 pages) that the trainer above has.


However, the book is built on top of the work of many other researchers and engineers as well as Evans professional experiences. Because of this, when a newcomer tries to decipher the technical strategies suggested by Evans early-on, they might miss the importance and nuance of bounded context, context maps, etc. because you're struggling with SOLID, Design Patterns, and many other assumed pieces of knowledge. Note that a lot of the technical strategies suggested by DDD are NOT new at all. They're simply organized within a "framework" of DDD. It's design patterns. It's SOLID. It plays a role in BDD. That's all.  BUT! The fact that it brings those underlying concepts together in such a graceful manner lend it to being a very efficient mode of showing applicability of those "more theoretical" concepts.


All that said, simply reading a book is not enough to grasp the entire body of knowledge presented by DDD. It takes 110% personal investment of resources, self-motivation and a supporting community to master, in my opinion.  It is not something one can do alone because a great amount of the topic-area (as far as nuanced decision-making skills that need to develop) is completely dependent on domain. Any role as a consultant, I believe, is a great benefit / multiplier to learning and applying DDD simply because you see differences in domain and problems that arrive.


The argument isn't that a single book can't be written to make the process easier. The argument is how do you get a shrimpy muscular structure lifting 400kg in 300 pages without dumbing down the process to the point that it is no longer applicable. And even that, I believe, CAN be done; but only on the shoulders of engineers before us and the willingness of the populus to seek out those resources.
In my head, I think the following are really some good next steps:

Teach newcomers how to ask the right questions.  This is an important skill and even more important in answering questions in domain-driven design. Go check out half the threads on http://dddinphp.org or the DDD/CQRS group. Half of the first responders end their posts with "it depends".
A set of books that proposed sample applications of DDD in different domains would be highly valuable. I would love nothing more than for an @everzet or a @mathiasverraes to catalog their consultancy projects as anonymized case-studies and publish them.  I'd then like to compare against Eric or Vaughn doing the same! :)
Increase awareness of communities like DDD/CQRS and dddinphp.org. They are ABSOLUTELY VALUABLE and will be a SIGNIFICANT resource to anybody looking to get into this stuff.  The fact that folks like Mathias, Greg Young, Kijana Woodard and more hang out in these communities and contribute is so valuable to folks looking to learn.