"It is...awesome!" was the reply, in the style I would learn to associate with Mike. Head nod for emphasis and big grin, as if remembering how it felt to watch the game-winning field goal in the 2001 Super Bowl.
In popular vernacular, "awesome" is reserved for CoD headshots, explosions in slo-mo, spring break vacations, and Pearl Jam concerts. Hyperbole. Idle interjection. Kid stuff. He-Man was Awesome in 1982.
A strong feeling of fear or respect and also wonder.That's what something that's Awesome gives you. Mike was right. Extremely right. One Blue Book, Red Book, and White Book later, I left the labyrinth behind forever.
What strikes me as so profound about Eric Evans' insight is just how astonishingly powerful it is. Not to mention elegant and intuitive. How did we all miss this? Thinking back to a time before I knew about DDD, I recalled instances where I worked on the design and implementation for numerous projects, some more successful than others. The successful ones, as I recall, involved a crude form of Domain Modeling and creation of a Ubiquitous Language. Sitting in a room with Sales and Domain Experts and hashing out the details made an incredible difference in the quality of the deliverable. Of course, my code wasn't that sophisticated back then, but worked reliably and could adapts as needs changed. I had no idea why this this was the case at the time, nor could I really hope to repeat that success consistently.
In my opinion, what's truly profound about DDD as presented in the first few chapters of the Blue Book is the tacit claim that tools and algorithms alone can't unravel the complexity at the heart of software. This is a human problem - a problem of language, of comprehension and consensus. Before a software engineer can ever hope to context-switch into his or her programming language of choice, the internal monologue intones, interrupting and nagging, "But what does it all mean?"
From the Domain Model spring forth so many valuable artifacts - illustrative diagrams, objects and database entities, Autonomous Services, events, user stories and backlogs, cross-functional teams, training manuals, glossaries, etc. I've even noticed that Domain Modeling can help Experts and stakeholders see inefficiencies and problems in their own business processes - without any help from an analyst or engineer. Awesome, indeed.
In some ways, I see the design patterns presented in the Blue Book as secondary. Don't get me wrong, Aggregate Roots, Value Objects, Bounded Contexts, and Anticorruption Layers are extremely useful in practice. But without a visceral understanding of the early chapters, I suspect one could mis-apply all those great ideas and end up in a very bad place. I'm not convinced the reverse is true. Without strong design patterns, it seems that one can still manage to build valuable software that follows the domain, albeit crudely.
I think it's the focus on language, concepts, and feedback loops that really makes DDD work. It's already in our brains, central to our lives as humans. We just have to rewire a little bit and take advantage of it.
No comments:
Post a Comment