10: 30 am - Eric Evans on Domain Driven Design. Here's Alan Knight introducing Eric:
And here's Eric starting his talk:
Domain: the critical complexity of most recent projects is in understanding the business domain itself. Note: This isn't true of all projects - there are technically oriented projects where the challenge is simply to overcome a technical issue (scaling, etc). However, most projects don't live there (contrary to what your larger companies and consulting firms would have you believe).
We tackle complexity with models - "when I say model I don't mean a UML model". Eric popped a couple of maps up as an example - an ancient China map, showing China at the center, and everything else on the periphery. Then a modern map, with North America at the center. The point being, that maps are models that serve a purpose (the importance of China, or the need to navigate from London to the new world) - and they then get picked up as "good enough" for other purposes.
"A model not reflected in the code is irrelevant". It doesn't need to be as realistic as possible so long as it serves that purpose.
His example is a cargo container routing system - and the model he popped up is a common one (especially with non-Smalltalk audiences) that starts with the database and works back from there - rather than starting with a domain model and dealing with the business users. So:
"A cargo makes a series of stops. At each stop it is unloaded from a transport and loaded onto another."
So, after taking to a business person, you end up with a few choices - in this case, are we dealing with stops or legs? This is the kind of choice you get confronted with in any business project, and it's not necessarily clear which is better (in the cosmic sense). What you'll end up with, if you analyze it, is the one that works better for you - you need to choose concrete reference scenarios rather than abstract, theoretical exercises. In the example (cargo shipping), Eric pulled up a map to show the route of a block from LA to Hong Kong. No help there - either model maps to this well enough.
What about re-routing in transit? That's also a viable scenario. Say the customer calls and says "it turns out that I want one of my containers to go to Seattle instead (or Dallas)". Here we have a distinct difference between the two models. With a stop based model we can add itineraries as we go, by appending a new itinerary after truncating the old one. What about the leg based model? The re-route seems easier than the other one, so this scenario tips that way. In general, you need to examine more and score them. In general, you select for the models that make the hard problems easier (the simple ones can be solved either way).
You use models then as a reference for determining what models make your most challenging scenarios easier to solve. We need tools that let us express models without getting bogged down in technical detail. Many people try to make that equivalent to: "Need tools that allow less skilled developers to use parts made by smarter people".
That latter theory is what drives Java, .NET, and the entire mainstream. When I attended this talk at ot2004, that was Joshua Bloch's entire explanation for API design - he posited a pyramid, where most developers live at the bottom. In fact, when I spoke to him afterwards, he told me point blank that Java developers weren't smart enough to use tools like Smalltalk. This is the mindset of the people delivering tools to the mainstream.
Back from my min-rant - Eric doesn't have a lot of patience for that, or for visual programming, or for UML driven theories that try to raise the abstraction level up. Language is our fundamental abstraction tool - and Smalltalk is one of the best languages for expressing a model. Back when Eric started with Smalltalk in the 80's, he figured that we would have something better than Smalltalk by now - and instead, we have Java.
Ok - what are Eric's currently favorite modeling tools?
- Whiteboard (with digital camera) - post results to a Wiki. Or the smartboards that can push directly to the network
- Smalltalk browser
- Unit tests
- Mouths and Ears
Drive the Design from the Model. Models are distilled knowledge, not knowledge gleaned from some over-arching upfront analysis. Also - Smalltalk code is easier to manipulate and change after the fact, which is important - because we never get it all right the first time. [ed] - this is one of the reasons that I think "final" is such a terribly bad idea - it makes an early assertion of perfect correctness.
many problems arise when the model does not match the customer's way of thinking. A bigger problem is what Eric calls context matching. He showed a picture of the fastest human powered rowing - an 8 team boat (the kind used in competitions). The reason that larger teams aren't slower is the fact that people tend to get out of synch with each other. The same thing happens in software. On large projects, there are always multiple models.
You'll get this problem even on smaller teams - it's not unsolvable. Problems arise when teams try to come up with the "one true" model for everything (wherein everyone works with a sub-optimal design for their part of the problem. With multiple models, there is a translation cost.
There are many teams that live in what you can call an upstream/downstream state - one team depends on the work of another, and is actually - to a large extent - controlled by it. To get better coordination you need trust and communication (picture a relay race, where the runner in front runs fast, holds their hand back, and relies on the prior runner to place the baton in their hand). You need to build up a complex "anti-corruption" layer only if you don't trust the upstream team.
Important: Map the contexts as they are, not as you wish them to be. For more information:
Previous Topic
