DDD patterns as “elegant support”

I've got quite a challenging response to my article about context mapping on InfoQ, that forced me to re-think about the article, and re-express some concepts, because some statements could have been misleading. I quickly mentioned the “classical” or “tactical” DDD patterns, such as Aggregates and Repositories and it looked like they’re the key to successful design. Well, they do help a lot, but the key to successfully implement a domain model is to understand the domain, achieving a creative collaboration with the domain expert. Practically this produces a small, but sophisticated, domain model that deeply reflects our understanding of the domain and supports our future, business-driven, changes. It’s impressive to see how a well designed model can accommodate changes.

So, the whole point is to keep your model tidy, small and clean. Most of the tactical DDD patterns serve the goal of keeping the domain model clean. Classes like Factories or Repositories, belong in the domain layer, have a well defined responsibility, but I think their overall purpose is to allow for the cleanest possible programming style in Entities and Value Objects, where most of the domain behavior is coded. In a certain way, the whole system of patterns is a sort of necessary scaffolding to allow the domain model to thrive. Patterns are not part of discussion with users and domain experts (this is pretty obvious, but ...zealots are zealots), they’re just part of the implementation. They allow the model to be technology independent, or decoupled from other portions of the application, they allow the model to be easily tested. They allow for complexity to be managed in an elegant and scalable way.

Sometimes elegance might be a problem
There is some aesthetic quality in a well crafted domain model. Some developers really like what a DDD model will look like. Guess what? I like it too. But that might deviate our attention to what really matters. Sometimes elegance has no business value, or better, is perceived to have none, by non-developers.

• “We’re refactoring this architecture to make it more elegant”
• “I don’t pay you to write Armani-dressed code! I want code that works and I want it fast!”

Has any of us developers being seduced by the beauty of numbers in an Excel balance sheet from the finance department? I guess not. It’s just a different language. So, sometimes it’s better to express “elegance” as “reducing the cost of change”. Sounds a lot more like business, and a lot less like a disconnected geek spending the time tidying up the code (by the way also cleanup doesn’t really work). We’ll still implement elegantly, but that’s our job.

So if you’re enthusiastically embracing DDD and try to apply what you’ve read in the book, be careful not to transform yourself in a DDD pattern zealot. Their elegance might distract attention from the real goal: they’re helpful and often indispensable, but the real target is in the domain itself, and in it’s business value.

Video of my "Possiamo fare di meglio" speech is out.

Big thanks to Yuri Valentini and all the friends from the Bologna XP User Group, for editing and posting the video. Here's the link.

Shared the Agile Day Presentation

The Slideshare version of my "Possiamo fare di meglio" (we can do better than this) presentation, is now available (in Italian) here.

I did my best to add comments to the many pictures, sooner or later also the video version will be available.

Article on DDD Context Mapping is out on InfoQ

We've been talking about Context Mapping quite a lot in the last days, I was also writing a lot in the meanwhile. The article I wrote for InfoQ is finally live.
Thanks to Srini Penchikala for taking care of me and of my messy review process.

A crowdsourcing experiment

Like one year ago, I decided to give my talk at Italian Agile Day as an open session with roughly the same schema: 15-20 minutes of impact talk, and 30 minutes of open discussion. I like this type of sessions because it’s not a “I know the truth” approach (I don't), but rather a way to make a small portion of a possible truth emerge from anyone in the room. So, even if I had some answers in mind, I preferred to focus on the questions, leaving the answers eventually open. I’ve seen some open sessions, but it’s not the kind of things that you practice every week (unless you’re leading a talk show), so please forgive me if it anything went wrong. Personally, I think it went a lot better than the year before: the discussion flew naturally and touched many of the topics I wanted to touch.

See it in another way
Ok, now think of me like Dr.Evil, with a “masterplan”: I’ve managed to hire about 200 among the best IT professionals I know as consultants for one hour. Basically for free. That’s my crowdsourcing experiment. And I had the feeling of so many little things emerged. Maybe not so clearly, maybe not so well formed or well expressed, but enough to make me think a lot in the following days.

On the way home, and later in the weekend some thoughts were a little clearer. I guess my personal follow up is worth sharing: at least ...I owe it to the participants. :-)

We’re making products, not software
Software is what we know, what we like to write, what we learned to produce. Some of us are really good in writing software, or in making their team write good software. That’s only half of the story: from the user perspective we see a product, not code. In the discussion, many mentioned user interface or the user experience. Which is right. But it’s still trees, not the forest. If we start thinking about the overall product we might realize that we need to see the whole a lot better than we usually do. Scrum has a good shoot on this by emphasizing the role of the Product Owner, meaning that we have a single responsible person (which is a gift from the gods in many organizations) for the whole product. There’s a problem up there, because so many times the whole idea of product is flawed, and we’re just writing software. Guess what... with a high probability of being completely useless.

I’ve seen so many projects missing their goals or their potential, just because the responsible organization didn’t have a clear idea of the whole product not to see a pattern here.

Non technical integration is not so easy
Ok, so we should try to have an all-round view to our product. Including also non developers roles within our project scope. Interesting but tricky. Especially if the team boundaries do not match with the company boundaries, which might happen quite often in a cross-functional team. But software-only teams can control continuous integration to a very high degree of efficiency using TDD, Continuous Integration and SCM tools. But this is only a portion of the product. Other professional might follow a different approach, that has nothing to do with TDD (or maybe it has... only on a different time scale), and the perfection we strived to achieve becomes frustratingly fragile. I guess there’s no easy recipe here, we’ve got to fall back on mantras like “inspect and adapt”: solutions might be a lot different from team to team. After all we’re humans. But it’s funny to realize that we sometimes we want to “integrate early and often” but “only software artifacts, please”. Postponing integration with non-software components of your project is even riskier.

This is definitely a hot topic, especially if you approach it from an enterprise management perspective: enterprise 2.0 folks are talking about more flexible approaches to collaboration, and this might be at odds with the benefit of a jelled team.

Reading suggestions after IAD2009

I’ve found myself talking about many different books with many different persons during IAD2009, here’s a summary of the books I more or less explicitly suggested:

• Pragmatic Thinking and Learning - Andy Hunt: some things happen by chance, some don’t some others you could make it happen.
• Agile Software Development, the cooperative game - Alistair Cockburn: an eye-opener on what’s around the code.
• Agile Retrospectives - Esther Derby, Diana Larsen: so little small details can make the difference between a good retrospective and a useless bloodbath.
• Collaboration Explained - Jean Tabaka: sometimes there’s so much about the people that we don’t really know.
• Agile Project Management with Scrum - Ken Schwaber: it’s not software development, it’s product development.
• Don’t Make Me Think - Steve Krug: how many times are we willing to transform a service into a pain?
• The design of everyday things - Donald A. Norman: guys, I hate bad design.
• Domain Driven Design - Eric Evans: there’s much more to this book than it looks (and looks like there’s plenty of stuff already).
• Patterns of Enterprise Application Architecture - Martin Fowler: the reference book for current architectural patterns.
  
• Agile Project Management - Jim Highsmith: it’s not all about the software,but it works.
• Slack - Tom de Marco: oops seems like so many things your organization is doing are wrong.
• Peopleware - Tom de Marco, Timothy Lister: still incredibly useful, if you haven’t read it you’re just pretending to manage software projects.
• Getting Things Done - David Allen: everybody’s talking about GTD, maybe because there’s something true in that.
• Clean Code - Robert C.Martin: you won’t go anywhere if you don’t agree on this.

Hope these might be useful to some.

Back from the Italian Agile Day 2009

I’ve seen skilled and curious colleagues. I’ve seen nice ideas emerge from different perspectives (more on this soon). I’ve met old friends and nice persons which I didn’t know and that I am now honored to know.

All this doesn’t happen everyday and everywhere.

Thanks to Marco Abis that every year make this magic happen. Thanks to everybody in the staff and to all friends from the Bologna XP Users Group, once more fantastic. Thanks to all the speakers, able to tell real stories without hype or fluff. Thanks to all the participants to my “talk show” sharing interesting ideas and thoughts. Thanks to the heroes that risked asphyxia to follow my Domain Driven Design mini-workshop.

Thanks also to Roberto Bettazzoni that reminded me what it means to be “Romagnolo”.

It has been a great day.

Thanks to everybody made it possible.