A: The answer to this is best done in light of a comparison. Is programming hard to learn? DDD is about as difficult to learn as any software language in that there are new terms and constructs to understand to skillfully apply these principles. So, one might say, if you learned how to program, you can learn DDD. If you are not a developer, then did you complete some education? A degree? DDD is about the same as learning a couple of subjects very deeply in a university. It is not a course that we know is taught in any university, so learning it will come from digging into resources like those on the Learning page.
A: No. The projects that benefit the most from DDD are those with a bit, or a lot, of logical and process complexity to them, no matter the actual size of those projects.
A: No. DDD is a paradigm that can be applied to start carving off functionality from a legacy system as well as start a green-field project. The paradigm has a notion of an Anti-Corruption Layer that insulates legacy or “quaint” systems from the new modules being designed and developed.
A: No and there may never be. This paradigm grows on the network of a community. It is a strange mix of a grassroots movement with an enterprise level skill.
A: For everyone it is different. Maybe you like reading. Maybe you are a learn-by-doing type of learner. Whatever is your learning style, use that to your advantage to dive in to the resources such as those on our Learning page.
A: A domain is the area of a company, organization, or agency that performs a group of related functions. Often those related functions are individually separated out to become labeled sub-domains. Domains/sub-domains are often referred to as the “problem space” and often need software to assist the improvement of the domain performance. Bounded Contexts are the major groupings of language, jargon, for those sub-domains often referred to as the “solution space”. Those solutions are defined in DDD terms at the highest level as Bounded Contexts. Though, often, a single subdomain can be served by a single bounded context, it is true that one bounded context might serve the needs of two or more domain areas. The key is the language definitions and their contexts that determine a good fit.