ORM: The Application Point of View

Ideally, the application point of view is the point of view of the users who will use the application to advance the interests of the organization. While the application must be computationally competent (more on that in a minute), the structure of the application should be guided much more by what the organization needs than by what the technologists are comfortable with. There is a school of thought that suggests that one can define the application in a way that is completely independent of the technologies that might be used to realize the application vision. I have never been able to pull that off. If you can do it, go for it. Meanwhile, back in the real world, we will get on with the work at hand.

Let us spend some time on domain driven design. Domain driven design means that we ask the user community to describe the things (e.g., concepts, documents, physical objects, and actions) that the business deals with. There are whole books written on this topic and I will not try to duplicate the contents of those books. There are a few points that are pertinent to this post.

First, the objects (classes if you like) have behaviors that are derived from the needs of the organization. That is, they are not just clumps of data items. They validate the data from which they are originally created and they validate any changes to that data. They derive other data from the data fed into them. They are greater than the sum of their parts. This also means that they may be valid or invalid and that this state of validity may affect what can be done with the object.

Second, the objects may be associated with other objects: they might own other objects (e.g., an order object owns the order line objects within the order) or they might collaborate with other objects (e.g., they might call an object to determine credit-worthiness of the customer).

Third, we want to test the fidelity of how well the domain model that we have constructed matches up with the real world. Generally, we will want to feed (almost) real data into our model and see if the results match up with what we see in the real world. The common practice is to sit with a user representative and work through a series of tests to test this fidelity. The expectation of this approach is that the user and the application developer will both gain a better understanding of the domain model. Typically, this is an iterative process that produces many versions of the domain model that eventually track fairly closely with reality. It is also possible that this modeling exercise also can trigger changes in the business processes: it may be the case that the questions that the application developer asks will reveal confusion about what various terms mean, gaps in the business process, or inconsistencies in how different users think that the "real" world works. In practice, the domain model and reality converge over time.

When the domain model and reality converge and when the domain model is complete in the sense that the set of tests adequately cover the logic of the domain model, we can say that the domain model is computationally competent. It is unambiguous in the sense that given a specific set of inputs, the domain model yields the same defined set of results each time. It is complete in that every possible set of inputs is tied to some outputs. Nothing falls through the cracks and nothing causes surprises.

This is not to say that it is completely correct. Our user representatives could be wrong. Reality could be in the process of changing. Our coverage metrics might be inadequate. But we can say that the model is valid and useful. And we can hope that when we discover the discrepancy between the model and the then current reality, we can make the changes quickly and with a minimum of fuss.

Note that the domain model does not address a whole raft of things that are really important. The domain model may recognize that the data in the domain model will be persisted to some form of data store, but how that happens is a decision that can be deferred to a later time. The same is true for security (authentication, authorization, and data protection), logging, auditing, and many things related to the "ilities". The key concept here is we could make and re-make the decisions about these matters several times during the lifetime of the domain model and those decisions should not change the content of the domain model. The choice of a SQL Server version or Oracle or MySQL or <Insert your favorite database here> should not affect the contents of the domain model. It certainly may affect the performance or scalability or reliability or ease of development but those are factors that are, at best, secondary to the quality of the domain model. (Did I mention that we were taking things to the extreme?)

Let me re-enforce this point. The application point of view says that we want to develop and validate the domain model without having to consider any of these secondary concerns. Properly done, the domain model will outlast multiple versions of operating systems, database management systems, messaging systems, and what have you. If we have to consider these issues too early in the process, we cause an unnecessary friction in the development process.