Repositories, package dependencies, and domain-flavoured exceptions

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.

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?
.

Relevant Pages

  • Re: Repositories, package dependencies, and domain-flavoured exceptions
    ... 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. ... 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. ... 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. ...
    (comp.object)
  • Re: Repositories, package dependencies, and domain-flavoured exceptions
    ... Always return a customer. ... > particular kind of Customer using an Account Number. ... The Repository is in the "domain" package, the exceptions are ...
    (comp.object)
  • Re: Repositories, package dependencies, and domain-flavoured exceptions
    ... The Repository is in the "domain" package, the exceptions ... > are in the "command" package. ... where are your Customer and Account classes, ...
    (comp.object)
  • RE: OSD Image Deployment via SMS advertisement (cannot connect to
    ... I rebuilt my test machine, advertised my package to it, and it's now ... showing the new software account as the username when trying to deploy the ... put in the advanced client network access account field. ... OS Deployment advertisement failed to install OS Deployment agent!. ...
    (microsoft.public.sms.swdist)
  • RE: OSD Image Deployment via SMS advertisement (cannot connect to
    ... One log tells you the account that is being used ... test machine and push the package again. ... OS Deployment advertisement failed to install OS Deployment agent!. ... Raising event: ...
    (microsoft.public.sms.swdist)