Java Reference
In-Depth Information
ease of use to convince the end client. The selected approach can be applied in a subse-
quent iteration to refactor the evolutionary architecture. Note that in this topic I will
discuss only the first iteration. Interested readers can take this up as an exercise for archi-
tecture refactoring. You can also visit http://www.opengarage.org to see the outcome of
this exercise.
Design
In the first pass of architecture, I managed to divide the application into tiers. Each tier
was decomposed into smaller layers with distinct functions. Now I will get down to the
design of the OMS application. It is important to educate the project development team
on the design of the application. This helps speed up development because it is now
based on best practices and established guidelines and patterns. Hence, before getting
into the actual design aspects, I will touch upon a very convenient yet powerful way to
publish design instructions.
I generally produce an HTML-based design directive as an agile design artifact.
Figure 7-4 shows a design directive composed in Javadoc style.
Figure 7-4. Design directive order management system
The design directive is composed just like a Javadoc. Each element in the Javadoc
describes a design concern. Since design aims to provide a high-level solution to the
problem at hand, each design concern is documented using the pattern template dis-
cussed in Chapter 2. In the next few sections, I will cover some of these design concerns
and address them using the Spring Java EE patterns discussed earlier in this topic.
 
Search WWH ::




Custom Search