Category: Development

Editor’s Note: Each month our development team comes up with a theme to focus on. We hold mini-summits and workshops, write blog posts, and use our Research and Development (R&D) time to explore the topic each month. For February, we have decided on Information Modeling and how it relates to a practice known as Domain Driven Design.

Information Modeling and Domain Driven Design

Among its other benefits, Domain-Driven Design has provided our team with a way of approaching software from a domain-centric approach. Domains are often complex; with so much focus on the model and logic in complex domain designs, it’s important to keep track of all of the pieces. Here at ProAce, we use a method called Object-Role-Modeling to accurately capture the semantic relationships within our model.

Domain Driven Design (DDD)

Overview

Domain Driven Design is a notion that may be familiar to plenty of software folks, but many in the business world have never encountered it. Fortunately, it is a concept that is immediately intuitive. Simply put, DDD states that for most software designs, the primary focus should be on the business domain and logic. Other decisions, such as the particular technology used should be secondary. It also provides a collection of patterns for building applications by focusing on the domain model first. Easy, right? Not so fast. The major problem with adopting a DDD approach stems from the fact that in most cases it can be incredibly difficult to completely understand a given domain.

Bank Example

Take the example of a bank. You have loan officers who are familiar with every aspect of generating, processing, and organizing various loans. You have executives who are concerned with the financial health of the institution and making decisions based on available data. You have HR people who have to worry about personnel, payroll, and interoffice issues. The list goes on. For any organization, you will find groups of people who are experts in a specific piece of that organization’s puzzle. Not surprisingly, we call these people Domain Experts in DDD parlance. The job of a developer writing software for this organization is to capture the knowledge of these Domain Experts and piece it together in a way that makes sense to describe the entire domain. We can start to see why this domain should take precedence in any good software design.

Common Sense

You may be thinking at this point, “Well of course, how else would software be written?” The sad truth is that much software gets created with features as a focal point. While this makes sense for a small project (an address book for example) for complex systems with hundreds or thousands of business rules this approach quickly devolves into chaos. Creating a complete and correct domain model at the outset enables a software team to quickly add features as necessary with the confidence that the underlying logic is sound. Likewise, should a business rule suddenly change we know exactly which piece of the software must be revised. There is no poking around hundreds of screens making the same changes and potentially overlooking a needed modification. So from a maintainability standpoint, DDD pays off immediately.

Business Value

Looking at the picture from a non-technical standpoint, you may be surprised at how well communication between developers and Domain Experts is facilitated once all players decide to commit to a DDD-based approach. The key to this is what is known as Ubiquitous Language in the DDD community. This is a vocabulary that is structured around the domain model and is agreed upon by all stakeholders in a project. In other words, when a loan officer is talking about a Loan it is exactly the same business object referred to as when a developer is talking about a Loan. When the software team is working in code and encounters the term Loan, there is no confusion as to what the object is supposed to be doing. There is no ambiguity; everybody is on the same page. Anyone who has been involved in a custom software project has most likely experienced the frustration of stumbling through a meeting filled with vague terms and sketchy understanding. Thanks to DDD, that pain may be largely alleviated.

Information Modeling

Overview

How do we describe a complex domain, then? There are plenty of accepted practices. For the technically savvy, a straightforward class library in code may suffice. For others a modeling language such as UML could be appropriate, perhaps complemented with workflow diagrams or even writing out the business rules in plain English. Here at ProAce, we use a method that we like to think is more complete than any of these strategies called: Object-Role Modeling, or ORM (not to be confused with O/RM).

Formalized by Dr. Terry Halpin in 1989, ORM is a fact-oriented method for modeling a “Universe of Discourse” (UoD) – otherwise known as a business domain. What makes this methodology differ from most is that it inherently focuses on information more than it does data. In fact, I like to summarize one of the primary focuses of ORM as:

Information = Data + Semantics

Having sample data is helpful but having a model describing your information is by far the best way to analyze that data. It’s also a great way to prevent a loss of knowledge.

[Update]

After discussing this with other members of the ORM community, I think it’s important to note that the power of ORM is in its powerful logical constraints. Because of its fact-based approach to modeling and the data structures that compose those facts (predicates and roles), constraints can be applied at very granular levels and they can also be applied to entire populations (which is where UML/ER and other modeling approaches fall short).

Information versus Data

Consider the following table:

Unless you were the one that created this sample data, all attempts at understanding the semantics behind the data require too many assumptions:

• What is the relationship between patient number and room number? (e.g., “patient/room assignments? Is it historical or current?”)
• Is the combination of these values unique?
• Are these values the unique identifiers of their associated entities?

Let’s pretend we’ve discussed it with our domain expert (client, some reputable source, etc.) and can summarize the first row in that table as:

“Patient number ‘142’ is currently located in Room number ‘101’”

Using NORMA, I can model this as:

Figure 1 – Patient is currently located in Room

Using NORMA’s verbalization browser, I get the following result:

Figure 2 – Verbalization output

What you may immediately notice from the verbalization is that our multiplicities are definitely a little off. We won’t want more than one patient in the same room so we definitely need to change that.

Figure 3 – Patient is currently located in Room (corrected uniqueness constraint)

Figure 4 – Corrected verbalization output

I have chosen not to focus on the details here. Instead, I wanted to show how the sentences themselves are what drive the modeling in ORM. The sentences are broken down into Object Types (entity or value), Predicates, and Roles and are then represented graphically as shown in the figures above. Simple, right? You’re right, the example is pretty straightforward but it only demonstrates a fraction of ORM’s capabilities. Some the highlights are:

• Algorithms (both formal specifications and tooling implementations) to go from an ORM model to:
  • ER diagram
  • UML diagram
  • Database schema at 5th normal form
• Powerful constraints
  • Value – specify a finite list of values (an enumeration)
  • Subset – specify that the population of two or more roles must exist in another population
  • Frequency – specify the minimum and/or maximum number of types an object must/can play a role in a population
  • …and several more.

We’ll be discussing more of the details as the month continues.

Why do we use it?

I’m often asked why my team uses this method. This will be the topic of many posts to come, but I think it can summarized by the following list:

• Documentation of semantic relationships
• Model validation

After explaining it the next question is always “how did you hear about it”?” The best way for me to describe it is that I’m lucky. A few of us here at ProAce had the opportunity to study under Dr. Halpin and provide valuable contributions to the Natural ORM Architect (NORMA) Project. It was under his instruction that we were first introduced to Information Modeling and we’re extreme evangelists for ORM. We may be biased about the tooling you’ll find that we love the process and the methodology more than we do the tooling.

Additional Resources

Do you want to know more? We’re speaking at the Austin .NET User Group meeting next month (March 2010) and will be hosting mini-summits and workshops this month. If you’re interested in attending, please email Joshua Arnold at jarnold AT (@) proace DOT (.) com. You can also visit the following list of links that we’ve compiled:

• The ORM Foundation
• ORM.net
• Object Role Modeling: An Overview (MSDN)
• Information Modeling and Relational Database, Second Edition (a.k.a. “The Big Brown Book”)

This is the introductory post for this month’s Information Modeling and Domain Driven Design theme. You can keep up with our conversations on twitter and the following RSS feeds:

• Domain-Driven Design
• Information Modeling
• Object-Role Modeling
• February 2010

Thanks go out to Jarrod for getting this post started and coordinating this month’s theme.