Re: Repositories, package dependencies, and domain-flavoured exceptions



Jason Che-han Yip skrev:
> I figured this group will have some insights so here's my story...

Snip.

>
> Question #1: Should this logic be part of the Repository?

FWIW, whenever I have a Repository class, I want it to be as stupid as
possible; it should store and return interfaces, but never access the
methods of those interfaces. I would store a CustomerFacade interface
in the Repository, and have the CustomerFacade responsible for mapping
an Account to a Customer.



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

Big question: where are your Customer and Account classes, in "domain"
or "command"? The exceptions related to those classes should be in the
same package as those classes themselves.

I would have suspected your "command" package to be some sort of
generic framework for handling Customers and Accounts, in which case
Customer and Account would be interfaces the implementations for which
you would have expected to reside in the "domain." If this had been the
case, then your Customer and Account interfaces, and all the exceptions
that they entail (and yes, even the Repository), would reside in your
"command" framework, and the implementations in your "domain" would be
given a opportunity to plug themselves into the "command" framework
before the action begun.

But forbidding all dependencies from "domain" to "command" makes
nonsense of that theory. So the, "Big question," remains.


>
> Question #2: Are Java packages really appropriate to be determining
> illegal package dependencies? I can accept that this might be a
> reasonable simplification.

Oh, good lord, yes, yes, and thrice yes. Java packages (and C#
namespaces) are absolutely, god-sendingly ideal as a hierarchical
encapsulation granularity for a large system. It's far more worthwhile
concentrating on inter-package dependencies than inter-class
dependencies within a package. You are doing The Right Thing.


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

This again makes sense if the "command" package is a framework
coordinating "command" interfaces that are implemented by classes in
the domain. This would yield "command"-flavoured exceptions in the
"command" package, related to domain implementations of "command"
interfaces.


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

Again, they should be in the "domain" packages if the Account class is
in the "domain" package.

And secondly: yes, yes, and yes again: the presentation package must
have access to all the classes that it wishes to present, and if the
retrieval of those classes throws error directly related to those
classes, then the presentation package must see them, too. Thus if you
add a different presentation package (say, text output), it will still
want to see those same classes, and must still cater for exceptions
encountered while retrieving those same classes.


..ed

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

.

Relevant Pages

  • 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: 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)
  • 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. ... The problem was that the Repository find method had AccountNotFound and AccountClosed exceptions in its signature. ...
    (comp.object)
  • 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)
  • Re: MSSecure.cab
    ... My Sync Host is my Site Server. ... >> permission to the SMSCliToknAcct& local account. ... >> Package Data Source directory and the package object. ... >>> Richard Threlkeld ...
    (microsoft.public.sms.admin)