Let's now re-focus to look at the structure of assets. An asset has a set of attributes called properties and a set of attributes called relationships. Property attributes are easy to understand—they are the characteristics of an object. For example, a car has a date of manufacture, a color, and an engine size. Or, a mortgage has a value, lifetime, and repayment schedule. A particular asset is identified by a particular set of property values. For example, my car might be manufactured in 2015, be white in color and have a 1.8-litre engine. Another example—your mortgage might be worth 100,000 USD, have a lifetime of 25 years, and be payable monthly. It's important to distinguish this difference—between the structure of an asset in general, its type, and particular instance of an asset.

Secondly, an asset also has a set of attributes called relationships. A relationship is a special kind of property—it's a reference to another asset! You can see instantly why this is important. For example, a car has an insurance document. The car is an object of value, and the insurance document is an object of value. Moreover, an insurance document names a policy holder. In our examples, both the subject and the object are assets, and they relate to each other in a way that provides essential meaning.

We'll see later that describing or modeling these relationships is an extremely important activity, because we're describing how the world works. In the previous example, we made a deliberate mistake—yes, really! That's because in the real world, it's actually the policy document that is central, as it names the car and the policy holder. In modeling, we call this an associative relationship, and we'll see why it's really important to get this kind of thing right. For example, nowhere in the nature of a car will you find an insurance document—a car is insured by virtue of the fact that it is named in a valid policy document. Moreover, if I want to insure more people to drive the car, I add their name to the policy document, not to the car! Much more on this later—for now, it's enough to remember that assets have properties and references, and particular objects have concrete values for these attributes.

It's also worth a brief mention on the nature of what makes an asset attribute a property rather than a reference to another asset. A simple answer is: when properties get too big, break them out into an asset reference! Of course, that's a very unsatisfactory answer! Why? Because I didn't tell you what defines big! A better answer is that a reference is required when a property satisfies a separate concern. This principle—separation of concerns—is a key design principle in any system. For example, the policy validity date is not a separate concern for an insurance policy, but the car and named drivers are separate concerns. This principle helps us to reason about insurance policies, cars, and drivers independently of each other, which in turn allows us to model the real world more realistically. Finally, on this aspect of assets, property and relationship attributes are domain-specific—they relate to the nature of the problem at hand. So, for a car manufacturer, color might be an attribute of a car—but for a paint manufacturer color is most definitely an asset type!