With all of these factors in mind, then, it's time to make some decisions about how the various component projects' objects will deal with keeping track of their data. In the interests of having a single interface around all object data access, we'll implement the BaseDataObject ABC described previously, or something very similar to it, and derive our final data-persisting concrete classes from a combination of that ABC and the relevant business object class built in the previous iteration. Finally what we'll end up with are classes for what we'll call data objects, which are capable of reading and writing their own data.

In the Artisan Application, since we don't need to worry about concurrent users interacting with the data at the same time, and since we don't want to burden an Artisan user with additional software installations unless there's no better alternative, we'll construct a data persistence mechanism by using local files to store object data.

In the code that will be running in a Central Office context, we will have concurrent users, at least potentially, so data storage will need to be centralized in a dedicated database system. There's no discernible need for a formal, database resident schema (though having one wouldn't be a bad thing), so using a NoSQL option should allow shorter development time, and allow some flexibility in case data structures need to change unexpectedly. We'll reexamine those options in more detail when we get to that portion of the development effort.