Using composite entities in data-driven apps

in my previous post, i discussed some of the problems that you run into when you try to have a single source of truth with regards to an entity definition. the question here is, how do we manage something like a customer across multiple applications / modules.

for the purpose of discussion, i am going to assume that all of the data is either:

• all sitting in the same physical database (common if we are talking about different modules in the same application).
• spread across multiple databases with some data being replicate to all databases (common if we are talking about different applications).

we will focus on the customer entity as an example, and we will deal with billing and help desk modules / applications. there are some things that everyone can agree on with regards to the customer. most often, a customer has a id, which is shared across the entire system, as well as some descriptive details, such as a name.

but even things that you would expect to be easily agreed upon aren’t really that easy. for example, what about contact information? the person handling billing at a customer is usually different than the person that we contact for help desk inquires. and that is the stuff that we are supposed to agree on. we have much bigger problems when we have to deal with things like customer’ payment status vs. outstanding helpdesk calls this month.

the way to resolve this is to forget about trying to shove everything into a single entity. or, to be rather more exact, we need to forget about trying to thing about the customer entity as a single physical thing. instead, we are going to have the following:

there are several things to note here:

• there is no inheritance relationship between the different aspect of a customer.
• we don’t give in and try to put what appears to be shared properties (contactdetails) in the root customer. those details have different meaning for each entity.

there are several ways to handle actually storing this information. if we are using a single database, then we will usually have something like:

the advantage of that is that it makes it very easy to actually look at the entire customer entity for debugging purposes . i say for debugging specifically because for production usage, there really isn’t anything that needs to look at the entire thing, every part of the system only care for its own details.

you can easily load the root customer document and your own customer document whenever you need to.

more to the point, because they are different physical things, that solves a lot of the problems that we had with the shared model.

versioning is not an issue, if billing needs to make a change, they can just go ahead and change things. they don’t need to talk to anyone, because no one else is touching their data.

concurrency is not an issue, if you make a concurrent modification to billing and help desk, that is not a problem, they are stored into two different locations. that is actually what you want , since it is perfectly all right for having those concurrent changes.

it free us from having to have everyone’s acceptance on any change for everything except on the root document. but as you can probably guess, the amount of information that we put on the root is minimal, precisely to avoid those sort of situations.

this is how we handle things with a shared database, but what is going on when we have multiple applications, with multiple databases?

as you can expect, we are going to have one database which contains all of the definitions of the root customer (or other entities), and from there we replicate that information to all of the other databases. why not have them access two databases? simple, it makes things so much harder. it is easier to have a single database to access to and have replication take care of that.

what about updates in that scenario? well, updates to the local part is easy, you just do that, but updates to the root customer details have to be handled differently.

the first thing to ask is whatever there really is any need for any of the modules to actually update the root customer details. i can’t see any reason why you would want to do that (billing shouldn’t update the customer name, for example). but even if you have this, the way to handle that is to have a part of the system that is responsible for the root entities database, and have it do the update, from where it will replicate to all of the other databases.