Determining Domain Objects
The purpose of this step is to maximize reuse by either using
or modifying existing Domain Objects or creating new ones, and to delegate
as much of the implementation of a Use Case State as possible to the invocation
of Domain Objects. This fosters reuse because Domain Objects, unlike USP Application
Objects, are candidates for reuse in that they may be used across multiple
applications.
The danger of the USP approach is that we could create
“bloated objects” and ignore reuse via Domain Objects altogether. For example,
we could create of “fat” State object for a Use Case and plop all the code in
there. How can we avoid this temptation?
Let’s face it, bad design is bad design, no matter the
framework used. Here are some guidelines to follow when writing State code:
Be sure the State plays the role of an
active Client Controller Object, not a passive Server Object
State code
exists for the following reasons:
To
fire entry and exit conditions
To
translate data types for i/o from that of the API required by the Server Object
Look for Server Objects to do the work
Rather
than “writing code” to solve the problem, think of it as an expedition
to
discover objects that can collaborate to solve the problem for you
By following these guidelines, we can change the implementation of the State over time without affecting the Use Case Controller. We also isolate State-specific code to a known and obvious location, which facilitates robustness and maintainability.