Tag Archives: object design

Why Domain Modeling?

Posted on by
Reply

One barrier to considering rich domain model architectures is a misconception about the value or purpose of a domain model. To some, creating a domain model seems a throwback to earlier days where design and modeling were perceived to be discrete, lengthy, and mostly unproductive activities.

When object technology was young, several notable authors made a strong distinction between object-oriented analysis and object-oriented design and programming. Ostensibly, during object-oriented analysis you analyzed a task that you wanted to automate and developed an underlying conceptual (object) model of that domain. You produced a set of task descriptions and a model of objects that included representations of domain concepts and showed how these objects interacted to accomplish some work. But you couldn’t directly implement these objects. During object-oriented design you refined this analysis model to consider implementation and technology constraints. Only then, after finishing design, would you write your program. The implication was that any model you produced during analysis or design needed extensive manipulation and refinement before you could write your program.

But even in those early days, many of us blurred the lines between object-oriented analysis, design and programming. In practice, how we worked was often quite different than suggested by the popular literature of the time. We might analyze the problem, quickly sketch out some design ideas and then implement then. We might use CRC cards to model our objects (which we would then discard). There weren’t distinct gaps between analyzing the problem and designing and implementing a solution. Sometimes different people did analysis while others did design and programming; but many times a developer would do all these activities. Sometimes, we created permanent representations of some models (in addition to our code). It depended on the situation and the need.

These days, I rarely see anyone produce detailed object analysis or design models. In fact, design and modeling have gotten somewhat of a bad wrap. Good object design is deemed too difficult for “average” programmers, and there isn’t time apart from coding to think about the domain and come up with any models.

The most common object models I see are created for one of two purposes: small conceptual models constructed to gain an understanding of significant new functionality; or informal design sketches intended to provide a quick overview to newcomers or non-code reading folks who need to “know more” about the software. A lack of modeling (unless you consider code or tests to be models—I don’t) is prevalent whether or not the team is following agile practices. The most common models I do see are very detailed E-R models that are more implementation specifications than models. They don’t leave out any details making it hard find the important bits.

Understanding and describing a domain and creating any model of it in any form takes a back seat to most development activities.

But if your software is complex, rapidly changing, and strategic and you aren’t doing any domain modeling, you may be missing out on something really important. If your software is complex enough, you can greatly benefit from domain modeling and thoughtfully doing some Domain-Driven Design activities.

For example, Domain Driven Design’s strategic design is a conscientious effort to create common understanding between business visionaries, domain experts and developers. Initial high-level domain discussions lead to understanding what is central to the problem (the core domain) and the relationships between all the important parts (sub-domains) that it interacts with. Gaining such consensus helps you focus your best design efforts and structure (or restructure) your software to enable it to sustainably grow and evolve.

But it doesn’t stop there. If you buy into domain modeling, you also commit to developing a deep shared understanding of the problem domain along with your code. Your mission isn’t to just deliver working functionality, but to embed domain knowledge in your working solution. Your code will have objects that represent domain concepts. You’ll be picky about how you name classes and methods so they accurately reflect the language of the domain. You will have ongoing discussions with domain experts and jointly discuss and refine your understanding of the domain. Along the way you may sketch and revise domain models. You’ll strive to identify, preserve, strengthen and make explicit the connections between the business problem and your code. When you refactor your design as you gain deeper understanding, you won’t forget to reflect the domain in your code. Your domain model lives and evolves along with the code.

As a consequence, there isn’t that big disconnect between what you code and what the business talks about. And that can be a powerful force for even closer collaborations between developers and domain experts.

Don’t Look for Grisgris

Posted on by
3

Gris-gris
African fetishes, charms or amulets.
Objects believed to have magical or spiritual powers to protect against evil or injury.

I received an email from a colleague pointing out a blistering critique of object technology in an article by Richard Mansfield, OOP Is Much Better in Theory Than in Practice, and a website devoted to defrocking object-oriented myths. The article starts out on this gloomy note and only gets more negative:

“Think object-orient programming (OOP) is the only way to go? You poor, misguided soul. Richard Mansfield contends that OOP is just the latest in a history of ideas that sound good in theory but are clumsy in practice.”

My colleague found this rant rather depressing. He has assumed for years that modern systems are ideally coded using OOAD—but still has struggled to make it happen in his own projects. He asked, what do I think of this kind of criticism?

Here’s my take. Any one who raises questions and concerns is good to listen to. There certainly initially was a lot of hype around objects. In the early days it was oversold. On the other hand, many of Mansfield’s comments remind me of someone who likes take broad swipes at something just for argument’s sake as well as someone who tweaks things for database performance. For him, objects get in they way. He’d much prefer to build software machinery optimized for relational database access. Reminds me of the classic ACM Article by Donald Knuth extolling the virtures of GOTO statements. GOTOs are useful sometimes. Objects, in my experience are even more useful—but not universally so. I know lots of people who have benefited from doing the hard work of creating a design with reusable classes with planned variations. Creating a model of interacting objects is hard intellectual work. Writing piles of code with cut-and-paste reuse is easier. It just is harder to maintain. I also know people who don’t see much benefit of objects because most of the code they write simply shovels data to and from a database with little behavior other than validity checks in between. While they may use objects to create GUIs and get results back from the database, they rarely invent objects of their own. And unfortunately, object programming languages still don’t co-exist very neatly with relational technology.

The value of object programming and design is apparent when you have significant behavior in your application and you create a model of interacting objects that does some significant work. Sure, you don’t need objects, just like you don’t need high level programming languages. But objects can sure come in handy. To discount the benefits of object-oriented designs simply because people don’t create good designs using them (another one of those correlation=cause false arguments in this anti-object writing) isn’t a rational argument. That’s like saying diets don’t work because fat people diet! There are also tangible benefits to developers who leverage extensive class libraries to build complex systems. I would hate to have to build all the complex software we do today without them!

I thanked my colleague for pointing me to this website and article. I’m going to give them a more careful reading which will probably result in some blog entries, if nothing else. Untangling any truth in a rant from fallacy is always good practice. But at the end of the day, we shouldn’t be looking for grisgris to be universally applied with blind faith to ward off all software ills. Instead we should be looking for solutions that work well for a given situation. I find objects a pretty good tool for a wide class of problems. In my own modeling and design over the last two years I’ve also looked at creating solutions using declarative approaches and seen how rule engines and objects mix (not very well unless you are very skilled at abstracting and writing generic rules with lots of meta-context). The value of objects hasn’t dimmed; my toolkit has simply expanded.