Jeff's Blog

This post series is going to cover the creation of a fairly simple creation of a set of Domain objects to cover the needs of a fictional Plebian University. The goal will be to create a set of Domain objects that will service a "tracking system" that encapsulates the management of people and facilities for this university. The set of posts will be centered on the Domain objects but we can't really fully develop those objects without knowing a little about how we want to approach persistence and how we want to handle business logic.

Sure there are hundreds of examples of domain object creation, so why bother posting on it? First because I need to update my canned library. Second because I want to take a deeper look at some of the stuff coming up in .Net 3.5. Third because a lot of the examples use the Customer/Order/OrderDetail problem set, and while that set is rich, I think there's a little more complexity to be had in the classification of a scholastic institution. And lastly, well because the point of a blog isn't necessarily always to have all the answers, rather sometimes it's about testing yourself. Key to that notion is that I've always been a Web-Developer, at least at heart, and one of the big implications of that is the tendency to start the design process from the point of view of what the UI can possibly do. In this case I really am going to try to stick to a true domain level mapping of my problem set, and not get bogged down to heavily in how I'm going to deal with the problems from the UI.

One of the problems I like that the scholastic model presents is how to handle professors who are students, or students that are employees. From a persistence (DB) level it's pretty easy to see a Person store, and a PersonRole store that allows multiple Roles per Person. In the domain level I can choose to split these out into firm types, or more closely model the persistence layer waiting until the business object layer to make any distinction. However we decided to cover that ground I want to make sure I can explain my reasons in plain English such that my fictional End Users will be able to comprehend both the correctness and implications of my choices.

Another good problem is the idea of forced generalization. Consider that a common scenario in our fictional university is the temporary repurposing of facilities. Say a classroom that is being used for chair storage. I need to be able to represent this room both as a classroom and as a storage room, so something like the Roles classification system seems logical, but what about rooms that are multipurpose such as storage and rehearsal space. Or facilities that need to be reclassified solely on the basis of its current occupant like a yoga studio that's also a creative writing classroom and Daycare playroom. How are we going to represent this type of flexibility while still providing a meaningful representation of the universities facilities, what's the role of the Domain and what's really a Business Logic Layer decision, these are the types of questions I want to answer.

The other part of this series of posts is to help layout and examine the evolution of requirements. Anyone with at least one project under their belt will know the humor found in the schedule marker "Requirements Complete". To the best of my knowledge, there has never been nor ever will be a "requirements complete" state for any business software project. For this post series I want to have an informal approach to requirements. There'll be some high level requirements, but in general we won't flush them out until we're in a specific problem space. Also the requirements will be focused on the Application level and not on the Domain. Partly that's to make their expansion somewhat realistic, and partly to allow me to be vague in laying them out.

Requirements:

• The final Application needs to track all students and staff, full-time and part-time, exempt and non-exempt, current and former.
• The final Application needs to track all Colleges, both enrollment, usage of facilities, staff, and students who's major's fall into that college and students fulfilling requirements
• The final Application needs to track all facilities, both buildings and grounds.
• The final Application needs to track on campus student housing needs.

Okay seems simple enough. The plan is to break off each Domain object by itself, with some exceptions like Person and PersonRole type groupings. Hopefully when this is done there'll be a nice set of domain objects we can use for future sample projects. And the next set of posts will be consuming these objects in Business Logic Layer.