SD Chapter 6: Developing Domain Classes

As the book says, "domain classes are at the heart of the software architecture".  They are the key element in understanding any system.  The book lists the main steps of developing domain classes as different sections of the chapter.  Here they are in the highlights version (or Reader's Digest version, however you want to describe it):

1.  Reading a Design Document--A design document is described as a document that contains a domain analysis, a requirements analysis, and a set of use cases.  These are used in the following ways:

• domain analysis: describes how the current application works including any existing software that may be used to support that application
• requirements analysis: identifies the activities that the new software must support
• use case: provides a transformative view, showing how the system should support specific kinds of interactions between types of users (called user roles)

2.  Identify Classes and Modules--When reading the requirements for a new system, developers should look for the "big picture" nouns.  Basically the ones that can be abstracted into classes or modules, which are the major elements in the system design.

3.  Identify Instance Variables--Here, we look for detailed entities in the use case that characterize the state of an object in a class

4.  Identify Methods and Functions--You want to look for information that helps designers specify actions that need to be implemented for each class.  In a nut shell, you're looking for methods or functions.

5.  Reading Code--This one is pretty much a no-brainer.  I mean, how can you work on developing a system or work on a current system without reading the code?  Developers will get the code base and read to find the information they need.  There are 3 main goals here:

• To understand the overall architecture and functionality of the existing software
• To learn the vocabulary established by the domain classes
• To identify the extent to which the code must be referenced before it can be modified to support the functions of the new system

When reading the code base for the frist time, developers are advised to start from the top, look for classes with unique keys, and avoid the temptation to refactor.

6.  Examining the Domain Classes--The domain classes characterize the central concepts in a software system.  Basically, the define a name space that permeates the entire application and its documentation.  The names themselves originate from the user's domain, so that they characterize objects and actions with which the users are already familiar.

7.  Adding New Features--The client or group of end users of a software system usually provides the catalyst for adding new features to an existing software system.  As the developer, it's your job to make the necessary changes to the current system to add the features.  The system developers should have good communication channels with users, that way if there is a problem or new needs they can be quickly transmitted and resolved.

8.  Top-Down Analysis/Bottom-Up Development--Going along with "Reading a Design Document", after the key elements are identified (top-down analysis), their implementation evolves through the code base (bottom-up development).  This is done by first revising the domain classes, then the database modules, and finally the user interface modules.

9.  Documentation and Bulletproofing--Whenever a new function is designed, it should be documented using standard practices and appropriate preconditions and postconditions.  This is particularly important for non-trivial (non-getter and non-setter) functions.