Category: Architecture

Adventures In Domain Modeling 2: What Are You Doing?

At the core, most business systems deal with Parties and how they interact with each other. There are other things that we model within a business system. But pretty much it comes down to Parties and Transactions:

  • A Customer  makes a Purchase of a Product from a Retailer
  • A Supplier sends a Shipment of a Parcel to a Consignee at a Location
  • A Student creates an Enrollment in a Class taught by a Professor
  • A Doctor makes a Diagnosis on a Patient
  • A Customer makes a Payment to a Provider
  • A Candidate submits an Application for a Job at an Employer

Notice that each transaction has two parties participating. Also notice that in most cases, the parties have a different name. Giving entities within your system meaningful names is important. It’s one of the key concepts of Domain Driven Design: the Ubiquitous Language. The down and dirty details of the Ubiquitous Language is that your technical team and your business team should speak the same language and that language should be reflected in the code. This puts the onus on developers to learn the business speak (despite how funny Dilbert makes business speak sound). What it boils down to is that when you capture a concept from your requirements gathering, use the same word the domain experts use. There is no need for translation when you do this.

Also noteworthy that the Transactions are Nouns not verbs. Traditionally, when first being introduced to object design, we learn that Nouns are Classes and Verbs are Functions. We specifically made the transactions in our models nouns. A simplistic way of describing the transactions would have been :

  • A Customer purchases a Product from a Retailer
  • A Supplier ships a Parcel to a Consignee at a Location
  • A Student enrolls in a Class taught by a Professor
  • A Doctor diagnoses a Patient
  • A Customer pays a Provider
  • A Candidate applies for a Job at an Employer

Rather than representing the transactions as separate entities we are implying the transactions are simple functions on the entities involved in them. We’re losing some of the resolution of our model. An even more naive model follows:

  • A Party purchases a Product from a Party
  • A Party ships a Parcel to a Party at a Location
  • A Person enrolls in a Class taught by a Person
  • A Person diagnoses a Person
  • A Party pays a Party
  • A Person applies for a Job at an Organization

In the end, there is always a person or organization involved in transactions. But these parties have specific roles within the transaction. What’s more is that the same party might play different roles within different transactions. For instance, in a two ended retail system (think Amazon), it’s possible for me to be a customer in one purchase and a retailer in another. By separating the Roles from the Parties playing them, I’m able to distinguish between the two and I won’t overload my Party object with responsibilities. I know that the responsibility of the Customer is to make a Purchase.

So far we’ve covered three of the four archetypes in Color Modeling, the Party/Place/Thing (Parcel is a thing, location is a Location), the Role, and the Transaction. Actually I lied. We covered all four in a blink and you missed it moment. The Product in the Purchase transaction is not a Thing…not in our archetypal definition. The Product is actually a Description. If I purchase Assassin’s Creed for the Xbox from Amazon, yes I receive a physical thing. But that individual item is no different to the system than the hundreds of other copies of Assassin’s Creed for the Xbox Amazon might have in any of their dozens of warehouses. They are for all practical purposes fungible. That Product is an example of the Description Archetype. When the system cares about the identity of a specific item, like a VIN for a vehicle or a Serial Number for a Console, it becomes a Thing. The Parcel is a thing because it has a Tracking Number and is not fungible with other parcels being shipped.

Adventures in Domain Modeling Part 0

This is the first in a series on Domain Modeling. The other parts include:

Part 1: Who Are You?

A question that I’ve answered a few times over the years is some variant on “how do I get better at Data/Domain Modeling?” I put an answer giving the resources I used to get better at modeling here on Quora, and am repeating it here. Over the next few…weeks? Months? I will be diving into these resources and walking through implementing a system built using the techniques provided in the books as we discuss them. So without further ado, I present an approach to become better at Data Modeling.

A good way to learn good design is to study good design. To that end, I recommend Len Silverston’s Data Model Resource Book. It comes in 3 volumes.

Volume 1 Covers Universal Data Models. The entities and relationships that are universally applicable no matter what project you’re building. A lot of these models form the foundation of CRM, ERP, HR, Accounting, Shipping, and Inventory Management systems so understanding them will help you understand the needs of people using those systems.

Volume 2 Covers domain/industry specific models. It builds on the Universal Models and adds new entities and relationships to cover basic needs for some of the primary industries:

  • Financial Services (banking, investments, trading, etc.)
  • Professional Services (Billable services, project management, time keeping, etc.)
  • E-Commerce (catalogs, customers, orders, web traffic, etc.)
  • Manufacturing (products, bill of materials, orders, production management)
  • Healthcare (patients, treatments, providers, insurance, referrals)
  • Insurance
  • Travel
  • Telecom

Understanding these two sets of models will help you get a sound foundation in data modeling especially with the surrounding discussion about the significance of these models. What’s more, having studied them, you will be able to talk more knowledgeably about the given industries.

Volume 3 is where things get interesting, it provides a list of data modeling patterns and how to apply them to design robust and flexible data models.

Next up is David Hay’s work that builds on Silverston’s. He has 3 books:

  • Data Model Patterns: Conventions of Thought
    amazon.com

    : Presents an approach to data modeling including rules of thumb for making your data diagrams more organized and readable. He also presents a number of business entities and relationships that explore concepts within business a little more deeply than Silverston’s. You’ll see diagrams for contracts, work orders, lab work, document management. They supplement and augment the Volume 1 Universal Models quite well.

  • Data Model Patterns: A Metadata Map: basically talks about modeling a system for building software. If that makes any since. It takes the Zachman Architecture Framework and builds a model to support the concepts found therein. Basically if you want to build a system to manage software delivery processes, this is the place you should start looking.
  • Enterprise Model Patterns I honestly can’t tell you what’s in this book because I haven’t read it yet. I read the prior two before he released this one. But it’s on my backlog and you would probably do well to at least give it a passing glance.

Finally, comes the book that taught me everything I know about Object Modeling (and from it Data Modeling):

Java Modeling in Color with UML. Don’t let the name deceive you. This book presents an entirely new way of looking at data modeling. It is object-first, but you should be able to translate to relational models after your experience with the prior books in this list. Trust me, once you understand the methodology in this book, you’ll become a master of data/object modeling. The basic premise is that there are 4 archetypes in any data model. And those archetypes relate to each other in a specific pattern. And if you follow the heuristics of this approach, you can use that pattern to identify missing elements of your model. Not only that you can use it for discovery when talking to business stakeholders about features and concepts in the system you’re designing.

This leads very well into the topic of Domain Driven Design. But I think I’ve given you enough to keep you occupied for a while.