Selecting the right mix of abstract and domain components is crucial to achieving an appropriate balance between investment and return.  Many a project has fallen into the tar pits of extreme analysis and overly complex inheritance hierarchies.  It may seem academically correct to root all entities in a few abstract base class such as item and person.  After all, what isn’t an item?  Documents, supplies, parking spaces, are all items in their own way.  The danger is in the details.  Consider a single students class schedule.  To fill a grid with a single semester’s information we might need to create instances of person, student, faculty, location, facility, time, calendar, item, document, and schedule.

 Seems a bit heavy handed.

So what is a viable alternative?  As with so many things related to design, it depends.  It depends on the limitations and capabilities inherent in the technology you chose to implement your solution.  It must pay homage to any known constraints of the deployed environment, as well as work with the skill sets of the staff. 

For this example;

• I am using Microsoft products,
• I have a capable but less than robust network,
• I will be serving a few thousand users who are spread out over several hundreds square miles but at least they are all in one time zone,
• Security is important but not mission critical within a user type (if one member of the faculty sees another’s schedule … no problem.  However a student should never see another student’s or any faculty information.)
• Management wants to conduct “what if” analysis of the course schedules and related faculty assignments,
• The team in predominantly mid level coders with a mix of Java, .Net, SQL server, and Oracle backgrounds, but has one very strong .Net developer as its lead.

 The immediate effects these constraints imply include;

• Being more stateless than not,
• Using OS based groups and roles,
• A high likelihood of implementing data level replication so that a given population is as close to their data as possible,
• Possibly creating a separate reporting facility for management, and
• Using a real database to perform fast aggregation activities.

 I would consider a significantly simplified design, more like this;

Schedule is arguably a core element in the domain.  It interacts with nearly all of the other elements in the domain.  It is certainly worthy of the creation of a simple callable façade. The heavy lifting, the aggregation of the various components of the schedule are delegated to the database engine via a stored procedure.  This allows use to implement security, pooling, partitioning, and replication.  At the heart of the action is the need to find the union of the various datasets.  The database already has the current values used to calculate a result.  Our tool, in this case SQL Server is a highly performant, scalable set theory processor.  In addition to meeting the needs of the environment, it limits network consumption by avoiding the various inter-object calls and their calls to the database for state information on construction.

Additional entities would be added AS NEEDED.  Architect for the largest possible known solution but build the smallest, simplest solution possible.

So what is the right mix of abstract and domain components for your enterprise?  Here are my top three questions to ask your self;

1)  What applications exist today (real and imagined) and how do they overlap?  In some circles this is called the enterprise portfolio.  Assuming you are not looking to do enterprise re-engineering, you need to create a map of the users and their tasks across the entirety of the business.  No other exercise will give you the breadth and depth of understanding needed to identify the core entities and services suitable for promotion to Domain component.

2)  What is the direction of the business and what might change?  It would be a best unfortunate to establish domain components representing aspects of the business about to be sold abandoned, and negligent to fail to account for a portion of the business slated to be acquired.

3)  What, in real numbers, are the capabilities and weaknesses of your IT infrastructure?  Enterprise solutions require communication and in our case that means networks.  If they are ineffective or missing entirely you might want to push enterprise architecture off for a while.  If they are in some areas than others, you have an opportunity to work with the IT infrastructure teams both identifying the issues and [balancing the usage or their prized assets.