Category: System Design

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.

Protocols are for Interop

I had a quick back and forth with Clemens Vasters via twitter about his views concerning MQTT. I definitely understand his frustrations at the way the protocol is being marketed, but my view as a newcomer to the “IoT” environment was that MQTT is a perimeter protocol to make it easier to get a message into your system from a simple device. The only thing an MQTT endpoint should be doing in my eyes is handing off the message to an internal bus so that it can be further processed.

Clemens mentioned to me that is not how it’s being sold and we both agree that it does have its place as a perimeter protocol. This brings me to my big point. Your infrastructure should not adhere to an external protocol. Protocols are for interop, and as such are limited to what a committee of implementors can agree on. Internally, you should be using a much more efficient and targeted means of communication. Take for instance the OBD-II protocol. Automakers are required to support it by law, but internally, they use their own messaging layer that is much more efficient and of course supports more functionality.

Too often I have seen projects pick up the next big buzzword and adopt it without concern as to its best application. SOAP/WSDL is one example. When I hear people asking if they should implement their internal services using SOAP when internally they’re using a homogenous environment it makes me want to pull my hair out (of course this is not as frequent because SOAP isn’t en vogue anymore. Now everyone wants to be RESTful although some of the very things that the RESTafarians were railing against (bloated protocol) are making their way into RESTful frameworks. It’s as if they’re realizing that Metadata for automatic discovery of an API might be a good thing (go figure).

But I digress. I once worked on a project for a major player in the financial sector and their entire application used FIX internally to communicate between components. Gone were the concepts of Object-orientation, if you wanted a property of a particular message, you had to query it from the message structure. To make it simple, it was not the most efficient process (and this was for a realtime system for Forex trading where milliseconds in delay can be the difference in making a profit and eating a loss).

If someone is selling you a protocol as a solution to build your product around, you should ask yourself what’s in it for them. Better yet, tell them “I’ll get back to you on that.” If you want to support a protocol in order to simplify integration with other products make sure that the protocol stays where it belongs, on the outside of your system.