Data Store Architecture - sounds pretty scary doesn't it? You get these horrific visions of server rooms and SANs across WANs... when it's something that every single Domino Developer does on every single application that they work on. At least they often start with Data Store Architecture. Don't believe me? That's okay - maybe by the end of this article however you'll see things my way...

One of the first things that I (and I believe many of us developers) do when getting started on a project is to sit down and Napkin-Develop the overall solution. It's this initial blueprinting of the application where we should be working on the Data Store Architecture - at least at a first pass. And some of us do! We say "oh, we'll need a username field here....", etc.

The problem is that this is where the vast majority of the Domino Developers out there take their first mistep: they launch the Designer Client, create a new Form Design Element, and put a Field element called username on their Form.

What's wrong with this? Nothing... if you're not separating your UI from your Data. You're sticking to everyday Domino Development, you're right on-par with the rest. You decide whether that's a good thing or not...

What I do as of late, is to continue with the blueprinting phase of the application. I work out, often through pseudocode, my Data Store Architecture. I define the elements that I will need to track specific to the type of record that I am storing. I define the content type of the given element. I track the individual requirement, lbound, and ubound for the given element (do I need it, is it multi-value, etc.).

I map out what all of my requirements are in the application, all of the potential integration points with existing solutions may be, and I do so before I even look at a development IDE.

And I do this, which might seem like overkill to a lot of you out there, for what I think is a good reason. - so bare with me here...

I'll illustrate my point by hijacking my own article here - let's take a look at the ATOM APP entryType Schema. This is an open standard schema that, for the sake of this article, we'll say is exactly in-line with what we're developing.

 <xs:complexType name="entryType">
  <xs:annotation>
   <xs:documentation>
    The Atom entry construct is defined in section 4.1.2 of the format spec.
   </xs:documentation>
  </xs:annotation>
  <xs:choice maxOccurs="unbounded">
   <xs:element name="author" type="atom:personType" minOccurs="0" maxOccurs="unbounded" />
   <xs:element name="category" type="atom:categoryType" minOccurs="0" maxOccurs="unbounded" />
   <xs:element name="content" type="atom:contentType" minOccurs="0" maxOccurs="1" />
   <xs:element name="contributor" type="atom:personType" minOccurs="0" maxOccurs="unbounded" />
   <xs:element name="id" type="atom:idType" minOccurs="1" maxOccurs="1" />
   <xs:element name="link" type="atom:linkType" minOccurs="0" maxOccurs="unbounded" />
   <xs:element name="published" type="atom:dateTimeType" minOccurs="0" maxOccurs="1" />
   <xs:element name="rights" type="atom:textType" minOccurs="0" maxOccurs="1" />
   <xs:element name="source" type="atom:textType" minOccurs="0" maxOccurs="1" />
   <xs:element name="summary" type="atom:textType" minOccurs="0" maxOccurs="1" />
   <xs:element name="title" type="atom:textType" minOccurs="1" maxOccurs="1" />
   <xs:element name="updated" type="atom:dateTimeType" minOccurs="1" maxOccurs="1" />
   <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
  </xs:choice>
  <xs:attributeGroup ref="atom:commonAttributes"/>
 </xs:complexType>


A few things should jump out at you here, even if you're not familiar with the schema:

1. minOccurs="1" - read: "Required Fields"
2. maxOccurs="unbounded" - read: multi-value data elements
3. type="atom:..." - these are defined throughout the schema in XML, allowing us to know exactly what we're in for...

Now, imagine this. You need to write a front-end for an application that's utilizing the ATOM APP entryType schema. From those 20-something lines above, you have an immediate grasp on what is needed for the application to function as-intended. Your UI becomes a variable - it's sole purpose to facilitate the user's proper data entry by whatever means you have available to you.

I don't know about you, but I see this as an empowering and completely sure-footed approach to solution development!

So let's jump back to the world of Domino Development, and our blueprinting... what's stopping me from taking on this same approach? Instead of jumping directly into the Domino Designer client, I instead open up my favorite XML editor - say Aptana - and begin writing out my data store architecture in XML schema. Based on all of the blueprinting and pseudocoding, I should have a really good grasp on it at this point. What I don't have, I'll fill in as needed - but I'm doing this without playing around within a Domino Developer client where I may be distracted in thinking that the pixel-spacing for the name picker for username is off...

And at this point, why should I worry about the UI - I've architected my data store now completely independant of UI - I can literally create a UI in any technology I wish as long as it can communicate back to my application. To do that, we'll need a message broker - which is the subject matter for another (upcoming) article - but the point still stands: once you effectively separate the user interface from your data store architecture, anything is possible.

I'll leave this intro if you will with a few final thoughts:

1. Imagine having such an XML-based schema document for your applications.
2. Imagine needing to modify that application for whichever reason in 6 months to 1 year - and having that XML-based schema document.
3. Imagine walking into a project cold, but being presented with such a schema document.
4. Now, imagine if DXL was full-fidelity!