Re: Repositories, package dependencies, and domain-flavoured exceptions
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Tue, 26 Jul 2005 17:04:45 GMT
Responding to Yip...
I figured this group will have some insights so here's my story...
I have a Repository that will abstract the intricacies of retrieving a particular kind of Customer using an Account Number. It is possible that the Account associated with the Account Number is closed, or doesn't exist, in which case, no Customer should be returned.
Question #1: Should this logic be part of the Repository?
I had this logic in the Repository, however, we have JDepend (a Java package dependency tool) rules preventing references from "domain" packages to our "command" packages. The problem was that the Repository find method had AccountNotFound and AccountClosed exceptions in its signature. The Repository is in the "domain" package, the exceptions are in the "command" package.
The repository detects failures with particular semantics that are unique to the repository subject matter (e.g., Not Found). However, that result is likely to be interpreted differently (i.e., with different semantics) in other parts of the application. For example, one might choose in a GUI to treat the exception to mean User Screwed Up Typing Entry. One reason we partition applications into subsystems and layers is so that we can decouple such semantic dependencies via interfaces. IOW, the subject matters should be encapsulated as layers of subsystems and the interface should express the semantics of the client context. If so, the question becomes academic because each subject matter interprets the event in its own unique way.
However, at another level your example does raise an issue of what goes in the repository. The fact that an account is closed does not necessarily mean that the data should be inaccessible. That accessibility is something that needs to be decided on an application-specific basis because it depends upon the access context. IMO, having the repository generate an exception for a Closed account is incorrect; it should return the Account information with an appropriate attribute value to indicate it is closed and let the application decide how important that is.
To put it another way, whether the account is active or closed will be indicated in the repository by an attribute value. It is not the repository's job to interpret the semantics of particular values. So the repository should never make decisions that depend upon the specific semantics of the data that it stores other than the relational view of the RDM.
At yet another level, throwing an exception in either case is a bad practice if the Account ID is supplied interactively. One is then using the exception mechanism to validate user typos. That is a very expensive and fragile way to handle errors that are normally expected in the environment. One should build the application to handle such errors within the normal flow of control and use exceptions to deal with errors that are completely unanticipated (i.e., the software has gotten into an unstable state).
Apropos of the point above, the repository cannot know whether an error like Not Found is unexpected or not in the client context, so it should never generate an exception. If the client thinks it is truly unexpected, then the client should generate the exception when the repository informs it of the problem in the normal interface.
Question #2: Are Java packages really appropriate to be determining illegal package dependencies? I can accept that this might be a reasonable simplification.
Most of the coordination of domain objects are done in command processors which is why, I presume, these domain-flavoured exceptions are in the "command" package. There are also Struts (Java request-driven web app MVC framework) actions that are used to add errors to the view depending on what kind of exception is thrown by the execution of the command. I suspect that some kind of generic handler could have been used as the exceptions all contain keys to the messages that should be displayed. In any case, we have another JDepend rule that prevents using "domain" package classes in "action" package classes. So I would be inclined to move these domain-flavoured exceptions to the "domain" package but this rule prevents me from doing so.
Question #3: Should domain-relevant exceptions like AccountNotFound, AccountClosed be part of "domain" packages? And if so, should presentation packages be able to reference them in order to translate them into view-specific representations?
As the points above indicate, each subject matter should deal with the semantics unique to that subject matter and it should provide services to deal with all relevant contingencies in their context. Clients may or may not be interested in processing event within the service. If they are interested, they may have their own semantics to interpret them. So long as the subject matters are encapsulated by interfaces, one can decouple the semantics.
************* There is nothing wrong with me that could not be cured by a capful of Drano.
H. S. Lahman hsl@xxxxxxxxxxxxxxxxx Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
.
- Follow-Ups:
- Re: Repositories, package dependencies, and domain-flavoured exceptions
- From: Jason Che-han Yip
- Re: Repositories, package dependencies, and domain-flavoured exceptions
- References:
- Repositories, package dependencies, and domain-flavoured exceptions
- From: Jason Che-han Yip
- Repositories, package dependencies, and domain-flavoured exceptions
- Prev by Date: Re: Repositories, package dependencies, and domain-flavoured exceptions
- Next by Date: Re: OOP/OOD Philosophy
- Previous by thread: Re: Repositories, package dependencies, and domain-flavoured exceptions
- Next by thread: Re: Repositories, package dependencies, and domain-flavoured exceptions
- Index(es):
Relevant Pages
|
