Raible Designs

[TSE] Domain Driven Design with Eric Evans

I've arrived at The Spring Experience, 45 minutes late for the first talk. I tried to get up early, but decided I'd rather get 6 hours of sleep instead of 4. I'm now sitting in Eric Evans' Introduction to Domain-Driven Design talk and the room is packed. I've never seen Eric talk before, but he seems a bit unprepared. His PowerPoint presentation is not in full-screen mode, so you can see where he hasn't finished slides and such. He's also very soft-spoken and seems to have an interesting way of convincing the audience his ideas are good. I feel like I'm sitting in some sort of NPR Seminar.

This hotel is pretty damn nice, as well as huge. It reminds me of some sort of Vegas hotel, with the grand entrance and all. The wireless network doesn't seem to work, but it's probably a problem with the network and my MacBook Pro. Luckily, connecting via Bluetooth through my phone seems to work.

"Not all of a large system will be well designed". Any sort of design methodology that assumes that will be doomed. Sometimes this leads to failure, but most often it leads to mediocrity. The best thing to do is use pragmatic, strategic design. You have to decide where the utility of your model is extremely high. Then define boundaries around that model so you can build anti-corruption layers. When doing modeling, you shouldn't look for the model, but simply a model.

• Meaning is specific to a context.
• Usefulness is specific to some set of scenarios.
• Practicality is determined by enabling technology.

Technology should enable rich and precise model expressions.

Modeling does not suggest an upfront design phase. Models are distilled knowledge about the domain and tailored to the situation you're in. At the beginning of a project, you don't have that knowledge. An Upfront Design Phase is an excellent way to design your system on the highest level of ignorance your team will have.

Technology should enable evolutionary change of the model.

Spring is getting more minimalist as it progresses. The amount of XML that J2EE makes you use to get something done is ridiculous - Spring fixes much of that and makes it much more manageable.

We need tools that let us express models without getting bogged down in technical detail. If you use a modeling approach, you've chosen to use a sophisticated approach and tools won't dumb it down for folks that aren't as skilled to develop. You'll still need skilled developers to develop this type of system and make it successful.

We need tools to help raise the level of abstraction of programming. However, we don't need Visual Programming or UML Extensions. Language is our fundamental abstraction tool. Language starts with talking ... and coding.

Eric's Favorite Modeling Tools (currently available)

• Whiteboard (with a digital camera for persistence)
• IDE
• Unit tests
• Our Mouths and Ears

The ultimate technology would be one that got out of your way so much that you wouldn't even be aware of it.

Talks on Domain Driven Design today (and throughout the weekend) can be found on the session schedule. From the talks in this track, Ben Alex's talk on Sunday sounds pretty interesting. From this talk's description:

In this presentation we'll study an internal web application developed by a major Australian corporation. The application uses a "real object oriented", or ROO, architecture. That means we swapped out those anemic domain objects, fat services, and those repetitive DAOs for rich domain objects that utilize transparent persistence and encapsulate business rules.