Don’t throw out the Domain with the Design Methodology
Around 20 years ago Planet Software was being invaded. Attack of the killer Design Methodology. Every company just had to have one and there were plenty to go around. Objectory, OMT, Booch, Responsibility Driven Design, Catalysis, Fusion, Coad/Yourdon, Shaellor and Mellor, and the list goes on. All these Methodologies were championed by a design methodologist. All of them had their own take on how you should approach OOAD and what the different phases were. Underline all the nouns in your requirements specification and they are your classes! People did this. All of them had their own syntax for drawing class/object/deployment diagrams? Hmmm, should we draw a class as Cloud or Rectangle. All of them had their own take on the modeling semantics. What is an association? What is the difference between composition and aggregation? All of us, the industry at large, were in a mess. There was a lot of confusion turning into frustration. Something needed to be done.
OOPSLA’94, Portland Oregon. I remember attending a panel on Methodology Standards: Help or Hindrance. The room was packed. The industry had questions. The panel was jammed packed with design methodologists best positioned to answer their questions. There was a real atmosphere in the room. Mostly good but some bad. I, sat at the back, as a then OOPSLA student volunteer (great job), and witnessed the public birth of UML by the ‘Three Amigos’, Booch (Booch Method), Rumbaugh (OMT) and Jacobsen (Objectory) with their joint corporate mother, The Rational Corporation.
UML quickly killed off all competitors and become the standard way of representing designs within the object-oriented paradigm. And I still believe it’s still doing a good job of that. However, then came the rise of the tools. Vendors hooked onto the UML cash cow and we entered the dark period of tool oriented design. Teams were divided up into roles that the tools supported. You are a tester. You are a code monkey. You are a wavy hand designer. You are my ivory tower architect - go forth and build me a monster. You are my business analyst to protect the business from the implementation team, or is it the other way round, I forget. And finally, you are, i dunno, my domain expert. Yeah, let’s go with that. The process dictated the phases and roles. The tool simply enforced them. Developing software like this is painful at best and depressing at worst. These tools did a great job of cutting teams up and keeping them apart.
The common sense in the form of agile came along. People were already downing tools but the agile manifesto accelerated this. However, a lot of folks didn’t really get agile, instead they got lazy. Freed from shackles of tools, models and in-your-face processes, developers returned to coding because that’s what agile is all about, right? Nooooooo. But even if you aren’t doing agile, tool-oriented design is nowhere near as big as it used to be. That’s good a thing right?
Well, sort of. The question now is where do you keep your domain model? How do you capture and model the business? In the race to tool freedom, some people simply don’t see the point in domain modeling. Or place such little emphasis on it that it is reduced to a simple discussion at the start of the project and is rarely visited outside of an IDE. In these cases domain modeling is all one-way traffic that flows from the domain expert to the programmer. There is little or no feedback from the programmer back into the domain model. In fact, we no longer have a domain model but more an implementation model that we are continually translating business terms and tasks into.
So why the post. Well, I don’t think you need a tool to have a domain model. However, I think it can help because you need to revisit and change it a lot. I certainly don’t think you can generate a complete executable system from a domain model and that same domain model be communicative enough to convey its intent to all interested parties. I think every project should spend some time domain modeling. I think because its hard, and domain-driven design is much harder, people don’t do it, which is a shame. I think developers should feedback their thoughts back into the domain model to reflect the truth and not shield from the business. I think developers should learn to model and not leave that to other people. I think the domain model should be accessible and well understood across the team. I think that code should be more closely aligned to the domain model. I think that if you don’t have a domain model, your project is either short-term and/or very small. If it is not, what are you doing?