This is the "least discussed part of DDD, but possibly the most important."
"Not all of a large system will be well designed."
CMW: Multiple people so far have mentioned this: systems exist for reasons. They evolved the way they did for reasons. They were probably good reasons at the time.
Every system has deep assumptions. These are parts of the system that are difficult (or impossible) to change.
Common bad strategies:
Consequences of bad strategies:
Core: what makes your system worth writing? what do you do that distinguishes you?
Contrast Amazon use of ratings vs eBay. They're close in functionality, but Amazon would still be Amazon without them. eBay would not, because they're enabling trust without which nobody would use ebay.
Not core features, but core domain ==> modeling well in our core domain enables us to create great features.
Heroes work in the core domain
CMW: "Strategic" -- identify core, then make it kick ass
(UML representation of "Blind men and the Elephant")
CMW: his exlanation of resolving the different elephant models reminds me of Blues Clues. Kids shows get in your head...
Disambiguating models into one is doomed -- these are "Enterprise Models", "one ring to bind them all..."
Resolve model differences thru context map; what are integration points and the nature of the translation between them.
The amount we work on the model depends on where the model sits -- in the core domain?
Precision designs are fragile.
Sophisticated design and modeling require
Anticorruption layer: able to translate between models on different layers.
Do core domain development in a bounded context on a clean platform; you do not need to re-create the world to do this. It may mean you need to create a thick translation layer. This is ok.
Look for assets in the legacy system, think "That's work I don't need to do" rather than "It all sucks"