The unfortunate human characteristic in all of us is that we like rules when we’re in a new and unfamiliar situation, and hate them the moment we think we are experts. The problem is that rules are great for creating concrete things. If you want to build this then: do a, then b, if you have a c then do d otherwise do e. But it does not work with creating abstract things. And software development is all about building abstractions.
In the past few weeks, I’ve had a few instances where I realized that some people were, basically, asking me for DDD rules – steps for building an aggregate, when and how to use the specification pattern, etc. There are no rules for the noobs for these things. But I think I can constrain the environment so that the noobs can focus a bit more intimately with these aggregates and specifications. One rule I put down was “When working with the following … don’t work outside of this Java package”
Essentially, my proposition is that rules for noobs should constrain the learning environment, not the subject being studied.
f3yourmind 
rules/recipes need a predictable input.To me, the key to make them work is to restrict the domain to a simple and relatively narrow context so that they become easily “applicable”.
In very simple domains, rules may well be context free (that is, they can be widely applicable in most cases), but generally this is not the case.
There is a lot of variability and “it depends” in Domain-driven design, however. A good learning environment should probably be scenario/context driven and let the noob apply a recipe and grow from there. If the noob is exposed to enough cases, maybe he will start making the giant leap and quickly understand when to apply what he/she learned.
My 2c
Hi niice reading your blog