Registration Oasis

At at large university I was brought in to work on a web based student registration system that interfaced to their mainframe system. The systems was to be deployed using WebSphere and EJBs. The existing mainframe system was to be reused and interfaced to by the new system.

I didn’t know much about Session beans, or using the a web layer. I also didn’t know much about the domain, though it is one we’re usually familiar with at the surface: courses, sections, schedules, conflicts, registering, etc… There had been no work done modeling the application, or doing a UI. There had been work done on how to technically interface with the mainframe.

I sat down with my domain experts (mostly developers that had worked on systems there for many years. Occasionally I also talked to a systems analyst). From those talks I created a domain layer populated with appropriated classes – SectionLists, Sections, etc… I decreed that the middle tier would largely deal with this sane set of objects.

I made extensive use of the command pattern to deal with the distributed nature of the architecture. Those commands could then flow through the system. For example, there was a command to register a student for a particular section of a course. The UI layer could create this command and pass it to the mid tier. It would then be turned into an appropriate command for the mainframe host, processed, and finally the command result would be returned to the UI.

By making use of the model layer, and mocking up the host layer, the entire infrastructure could be tested with JUNIT. When the host interface portion was working, this could then be tested via JUNIT as well. It wasn’t till the end of the project that the commands were slipped into the ultimate
UI/EJB framework. I had many talks with the UI developer who challenged that the various layers were working. Since the commands all worked via JUNIT, it was almost always a case of improperly using them, or of improper environment setup.

By using a common set of objects, across the tiers (except the host), all layers could reuse the objects, the common vocabulary, and the behavior and constraints of the objects. (For example, instead of having simply a collection of Sections, a SectionList could prohibit duplicates, or enforce other application rules).

The effort was a prototype. I left the project but later learned that virtually the entire set of commands and domain objects went intact into the final version.

©2003, Bruce Gordon

Leave a Reply

You must be logged in to post a comment.

Domain-Driven Design Community