Loading ...
Sorry, an error occurred while loading the content.
 

Re: [domaindrivendesign] Re: Accounts and Members

Expand Messages
  • Farhan Kazmi
    I think you should question the value of the having the Account to Member relationship. Maybe you should reverse the relationship and make each Member
    Message 1 of 22 , Sep 28, 2006
      I think you should question the value of the having the Account to Member relationship.  Maybe you should reverse the relationship and make each Member associated with an Account
       
      On 9/28/06, andrewryan1906 <andrew1906@...
      > wrote:

      Richard,

      I struggled with this a lot in the beginning. It seems like, in a
      data driven app, so much functionality relates to repositories that
      pulling them all out into services would leave you with an anemic
      domain model and transaction scripts. But personally, I think
      injecting the idea of a repository into a domain object is evil.
      This is IMHO. Domain objects shoudl only be able to know about or do
      things relevant to their existence in a domain - the idea that a
      domain object should even know there exists a repository of other
      domain objects is, (again IMHO), against DDD.

      Any operation that requires accessing a repository should
      automatically be a domain service. That service may call domain
      model methods ONCE ITS GOTTEN THE ITEMS FROM THE DOMAIN.

      To give you a real world example, I have a class called Currency and
      a value object (struct) called Money. I wanted to implement a method
      called:

      Currency.Convert( Money moneyToConvert )

      Since Money has a Currency reference, I would essentially be
      converting Money.Currency to the Currency. The problem? I have to
      access the ExchangeRateHistory repository to do this.

      So, you're tempted to use the very sexy Dependency Injection
      princple to get the ExchangeRateHistoryRepository class into the
      Currency class and make it happen, right? But that would definitely
      be the path to the dark side.

      Why? Because your domain model isn't pure anymore. The concept of a
      Currency has been poluted with another concern - persistence. The
      fact that is IoC makes it better, but still not great. Put another
      way - could I pick that domain object up and use it in a completely
      different application? Once, for instance, that didn't have
      repositories, but wanted to pass in the ExchangeRateHistory as an
      XML string or an IDictionary? No.... b/c my class is coupled to the
      idea of a repository. The RIGHT way to do it is:

      Currency.Convert( Money money, decimal exchangeRate );

      Then have a service called CurrencyService that looks up the
      appropriate exchange rate and passes it to the domain object, WHICH
      DOES ALL OF THE WORK. This domain object CAN be used in difference
      apps, b/c the core work of converting from one currency to another
      IS part of the domain model.

      Back to your example - you need an AccountService with a
      LocateMember method. Placing the responsibility into an Account
      object of doing all of the things an account does (ACcount.Open,
      Acconut.IsValid, Account.Cancel, whatever) PLUS the responsibility
      of understanding that it exists in a repository and manipulating a
      repository is too much responsibility for one object.

      This is my 6 cents... anyone have any other thoughts?

      D

      --- In domaindrivendesign@yahoogroups.com, "Richard Rodseth"
      <rrodseth@...> wrote:
      >
      > I'm trying to be the DDD advocate on my team. A question has arisen
      > about injecting an AccountRepository into the Account entity in
      order
      > to implement Account.findMember.
      >
      > Currently there is a lazily-loaded set of members in the Account
      (we
      > use Hibernate), so findMember could iterate rather than use the
      > repository, but I supect that that design will have to be
      > re-considered to allow for large numbers of members.
      >
      > Personally, I would be comfortable with a business method on a
      service
      > which accessed the repository. But colleagues feel
      Account.findMember
      > () is natural.
      >
      > Any objects to calling a repository from an entity? If so, any good
      > alternatives in this case?
      >
      > Thanks,
      > Richard
      >


    • Randy Stafford
      Sure, I agree with that, and Eric says as much on p.105 - Services are a common pattern in technical frameworks, but they can also apply in the domain layer .
      Message 2 of 22 , Sep 29, 2006

        Sure, I agree with that, and Eric says as much on p.105 – “Services are a common pattern in technical frameworks, but they can also apply in the domain layer”.

         

        However that’s not what I intended with Service Layer – “Defines an application’s boundary with a layer of services that establishes a set of available operations and coordinates the application’s response in each operation”.  A Service Layer, as I documented it, is comprised of what Eric eloquently describes as “application services” on pp.106-107.

         

        Nor, I dare say, are “domain services” what the Fusion Method people intended with system interface in 1993 – “The interface of a system is the set of system operations to which it can receive [sic] and the set of events that it can output”.  Nor what Alistair Cockburn intended with Application Boundary in 1995: “Define the user interface to be outside the application proper.  Make all functions of the application accessible through a program-driven interface. … [D]etermine the services of the application.  Create a program-driven (not human-driven) interface, on the assumption that one day the application will be driven by a computer system.  The UI is one of several drivers.  All functions of the application must be accessible to the driving system.”

         

        This is one of those cases where a term (service) has multiple distinct meanings, and we need to be clear about which meaning we intend when we use the term in conversation.  Domain services are distinct from Service Layers comprised of application services.  Both ideas are useful and have their place, but should not be confused with each other.

         

        Best Regards,

        Randy

         


        From: domaindrivendesign@yahoogroups.com [mailto: domaindrivendesign@yahoogroups.com ] On Behalf Of aabelro
        Sent: Friday, September 29, 2006 11:46 AM
        To: domaindrivendesign@yahoogroups.com
        Subject: [domaindrivendesign] Re: Accounts and Members

         

        I personally consider that there can be Services in a Domain. They are
        not mutually exclusive. A Service usually provides, well, naturally, a
        service to an object. It does not hold internal state, because it's
        purpose is to provide operations for other domain objects. It
        encapsulates operations which do not belong to a specific object,
        either because the service is useful to more than one object type, or
        because it's something that should be separated from the object, like
        the task of communicating to an external system.

        Abel

        --- In domaindrivendesign@ yahoogroups. com, " Randy Stafford "
        <randy.stafford@ ...> wrote:

        >
        > It's good that you're thinking about allocation of responsibility
        > <http://c2.com/ cgi/wiki? AllocationOfResp onsibility>
        ; I believe that is
        > at the heart of object-oriented design. But I agree with Roger that it'
        > s perfectly natural, and pragmatic, for domain objects to depend on
        > repositories. I've written
        > <
        href="http://tech.groups.yahoo.com/group/domaindrivendesign/message/2327">http://tech. groups.yahoo. com/group/ domaindrivendesi gn/message/ 2327> in
        > this forum about that before, as the topic comes up often.
        >
        >
        >
        > Regarding service layers, as the author of the pattern, first let me
        > state that I began doing DDD in 1988 in Smalltalk without knowing any
        > different, because that's just how Smalltalkers did things. Back then
        > it was four-layer architecture
        > <http://c2.com/ cgi/wiki? FourLayerArchite cture>
        in single-tier or
        > fat-client/server systems, with nary a service layer in sight. As I
        > mused on the four-layer architecture discussion page
        > <http://c2.com/ cgi/wiki? FourLayerArchite ctureDiscussion>
        , I think the
        > advent of distributed object technology and n-tier architecture brought
        > about an evolution in allocation of responsibility which yielded what I
        > conceived as a service layer. I began using the suffix "Service"
        in my
        > software architectures in about 1997, in the context of CORBA and RMI -
        > based projects.
        >
        >
        >
        > But the idea was neither new or mine; it's timeless. The Fusion Method
        > people at HP were writing
        > <
        href="http://www.amazon.com/Object-Oriented-Development-Method-Derek-Coleman/">http://www.amazon. com/Object- Oriented- Development- Method-Derek- Coleman/
        > dp/0133388239> about it ("system interface", "system
        operation") in
        > 1993. Alistair Cockburn was writing
        > <
        href="http://www.amazon.com/Pattern-Languages-Program-Design/dp/0201895277">http://www.amazon. com/Pattern- Languages- Program-Design/ dp/0201895277>
        > about it ("application boundary") in 1995. And what are web
        services
        > and SOA now but service layers accessed through web protocols and
        > messaging systems?
        >
        >
        >
        > With service layer it was never my intention to take anything away from
        > DDD, and I regret that some people have interpreted a service layer as
        > an alternative to a domain-driven design. If you look at my example in
        > PoEAA, and how I articulated the pattern, you'll see that I
        > intentionally re-used the same example (Revenue Recognition) from the
        > Domain Model pattern, and I intentionally did not move any
        > responsibilities from the domain model to the service layer. Rather, I
        > added additional responsibilities that I don't feel are appropriate to
        > allocate to the domain layer. In my experience as an architect of
        > enterprise applications, I've seen certain typical responsibilities -
        > notification of stakeholders (including other systems) that an event has
        > occurred, control of transactions, interaction with external systems,
        > initial access of domain objects, etc. - that I just don't feel are
        > appropriate to allocate to the domain layer, based on some vague
        > romantic notion of reusability, separation of concerns, etc.
        >
        >
        >
        > In the end it's all about allocation of responsibility, and I
        > acknowledge it's somewhat of an art, with different styles and
        > preferences. Over the years my idealism has given way to pragmatism to
        > some extent. But when I build systems I still view service layers and
        > domain layers as complementary, and I don't mind at all letting domain
        > objects depend on repositories.
        >
        >
        >
        > Best Regards,
        >
        > Randy
        >
        >
        >
        > ____________ _________ _________ __
        >
        > From: domaindrivendesign@ yahoogroups. com
        > [mailto:domaindrivendesign@ yahoogroups. com]
        On Behalf Of andrewryan1906
        > Sent: Friday, September 29, 2006 9:34 AM
        > To: domaindrivendesign@ yahoogroups. com
        > Subject: [domaindrivendesign ] Re: Accounts and Members
        >
        >
        >
        > Everyone,
        >
        > I don't know. I read your replies a bunch of times I see what you're
        > saying - but I'd like a little more convincing that injecting a
        > repository into a domain object is a good idea.
        >
        > Here's my problem - I am fully aware that the repository abstracts
        > away the persistence layer, and that no matter what, the domain will
        > never know anything about SQL, XML, in-memory, etc... but I still
        > have issue with the domain object even knowing to access a
        > repository. Back to my currency example - a Currency object should
        > know how to convert Money to another type of Money based an exchange
        > rate (i.e., USD to Euro at a 1.4% exchange rate)... I think the
        > logic to go into a repoistory and look up the currency exchange rate
        > is OUTSIDE of the scope of the responsibility for a Currency object.
        > Many times when repository access is needed, different objects need
        > to be retrieved and other things outside of the scope of the object
        > have to happen. It's dangerous to start saddling domain objects with
        > the responsibility to access a repository and look things up, I
        > think - because they should understand how to interact with each
        > other in a world objects simply exist. HOW they come to exist (i.e.,
        > from a repository) should be in the Service Layer - I think.
        >
        > But I am open to other opinions.
        >
        > In particular Roger - I'm curious about your experience with a
        > service layer. Can you give a concrete example of how you did
        > things, and more specifically, how adding simple functionality
        > was "painful?" This would go a long way to seeing if I'm wrong
        about
        > this whole Currency/Account thing.
        >
        > D
        >

      • aabelro
        I fully agree with you. Abel
        Message 3 of 22 , Sep 29, 2006
          I fully agree with you.

          Abel

          --- In domaindrivendesign@yahoogroups.com, "Randy Stafford"
          <randy.stafford@...> wrote:
          >
          > Sure, I agree with that, and Eric says as much on p.105 - "Services are
          > a common pattern in technical frameworks, but they can also apply in the
          > domain layer".
          >
          >
          >
          > However that's not what I intended with Service Layer - "Defines an
          > application's boundary with a layer of services that establishes a set
          > of available operations and coordinates the application's response in
          > each operation". A Service Layer, as I documented it, is comprised of
          > what Eric eloquently describes as "application services" on pp.106-107.
          >
          >
          >
          > Nor, I dare say, are "domain services" what the Fusion Method people
          > intended with system interface in 1993 - "The interface of a system is
          > the set of system operations to which it can receive [sic] and the set
          > of events that it can output". Nor what Alistair Cockburn intended with
          > Application Boundary in 1995: "Define the user interface to be outside
          > the application proper. Make all functions of the application
          > accessible through a program-driven interface. . [D]etermine the
          > services of the application. Create a program-driven (not human-driven)
          > interface, on the assumption that one day the application will be driven
          > by a computer system. The UI is one of several drivers. All functions
          > of the application must be accessible to the driving system."
          >
          >
          >
          > This is one of those cases where a term (service) has multiple distinct
          > meanings, and we need to be clear about which meaning we intend when we
          > use the term in conversation. Domain services are distinct from Service
          > Layers comprised of application services. Both ideas are useful and
          > have their place, but should not be confused with each other.
          >
          >
          >
          > Best Regards,
          >
          > Randy
          >
          >
          >
          > ________________________________
          >
          > From: domaindrivendesign@yahoogroups.com
          > [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of aabelro
          > Sent: Friday, September 29, 2006 11:46 AM
          > To: domaindrivendesign@yahoogroups.com
          > Subject: [domaindrivendesign] Re: Accounts and Members
          >
          >
          >
          > I personally consider that there can be Services in a Domain. They are
          > not mutually exclusive. A Service usually provides, well, naturally, a
          > service to an object. It does not hold internal state, because it's
          > purpose is to provide operations for other domain objects. It
          > encapsulates operations which do not belong to a specific object,
          > either because the service is useful to more than one object type, or
          > because it's something that should be separated from the object, like
          > the task of communicating to an external system.
          >
          > Abel
          >
          > --- In domaindrivendesign@yahoogroups.com
          > <mailto:domaindrivendesign%40yahoogroups.com> , "Randy Stafford"
          > <randy.stafford@> wrote:
          > >
          > > It's good that you're thinking about allocation of responsibility
          > > <http://c2.com/cgi/wiki?AllocationOfResponsibility
          > <http://c2.com/cgi/wiki?AllocationOfResponsibility> > ; I believe that
          > is
          > > at the heart of object-oriented design. But I agree with Roger that
          > it'
          > > s perfectly natural, and pragmatic, for domain objects to depend on
          > > repositories. I've written
          > > <http://tech.groups.yahoo.com/group/domaindrivendesign/message/2327
          > <http://tech.groups.yahoo.com/group/domaindrivendesign/message/2327> >
          > in
          > > this forum about that before, as the topic comes up often.
          > >
          > >
          > >
          > > Regarding service layers, as the author of the pattern, first let me
          > > state that I began doing DDD in 1988 in Smalltalk without knowing any
          > > different, because that's just how Smalltalkers did things. Back then
          > > it was four-layer architecture
          > > <http://c2.com/cgi/wiki?FourLayerArchitecture
          > <http://c2.com/cgi/wiki?FourLayerArchitecture> > in single-tier or
          > > fat-client/server systems, with nary a service layer in sight. As I
          > > mused on the four-layer architecture discussion page
          > > <http://c2.com/cgi/wiki?FourLayerArchitectureDiscussion
          > <http://c2.com/cgi/wiki?FourLayerArchitectureDiscussion> > , I think the
          > > advent of distributed object technology and n-tier architecture
          > brought
          > > about an evolution in allocation of responsibility which yielded what
          > I
          > > conceived as a service layer. I began using the suffix "Service" in my
          > > software architectures in about 1997, in the context of CORBA and RMI
          > -
          > > based projects.
          > >
          > >
          > >
          > > But the idea was neither new or mine; it's timeless. The Fusion Method
          > > people at HP were writing
          > >
          > <http://www.amazon.com/Object-Oriented-Development-Method-Derek-Coleman/
          > <http://www.amazon.com/Object-Oriented-Development-Method-Derek-Coleman/
          > >
          > > dp/0133388239> about it ("system interface", "system operation") in
          > > 1993. Alistair Cockburn was writing
          > > <http://www.amazon.com/Pattern-Languages-Program-Design/dp/0201895277
          > <http://www.amazon.com/Pattern-Languages-Program-Design/dp/0201895277> >
          > > about it ("application boundary") in 1995. And what are web services
          > > and SOA now but service layers accessed through web protocols and
          > > messaging systems?
          > >
          > >
          > >
          > > With service layer it was never my intention to take anything away
          > from
          > > DDD, and I regret that some people have interpreted a service layer as
          > > an alternative to a domain-driven design. If you look at my example in
          > > PoEAA, and how I articulated the pattern, you'll see that I
          > > intentionally re-used the same example (Revenue Recognition) from the
          > > Domain Model pattern, and I intentionally did not move any
          > > responsibilities from the domain model to the service layer. Rather, I
          > > added additional responsibilities that I don't feel are appropriate to
          > > allocate to the domain layer. In my experience as an architect of
          > > enterprise applications, I've seen certain typical responsibilities -
          > > notification of stakeholders (including other systems) that an event
          > has
          > > occurred, control of transactions, interaction with external systems,
          > > initial access of domain objects, etc. - that I just don't feel are
          > > appropriate to allocate to the domain layer, based on some vague
          > > romantic notion of reusability, separation of concerns, etc.
          > >
          > >
          > >
          > > In the end it's all about allocation of responsibility, and I
          > > acknowledge it's somewhat of an art, with different styles and
          > > preferences. Over the years my idealism has given way to pragmatism to
          > > some extent. But when I build systems I still view service layers and
          > > domain layers as complementary, and I don't mind at all letting domain
          > > objects depend on repositories.
          > >
          > >
          > >
          > > Best Regards,
          > >
          > > Randy
          > >
          > >
          > >
          > > ________________________________
          > >
          > > From: domaindrivendesign@yahoogroups.com
          > <mailto:domaindrivendesign%40yahoogroups.com>
          > > [mailto:domaindrivendesign@yahoogroups.com
          > <mailto:domaindrivendesign%40yahoogroups.com> ] On Behalf Of
          > andrewryan1906
          > > Sent: Friday, September 29, 2006 9:34 AM
          > > To: domaindrivendesign@yahoogroups.com
          > <mailto:domaindrivendesign%40yahoogroups.com>
          > > Subject: [domaindrivendesign] Re: Accounts and Members
          > >
          > >
          > >
          > > Everyone,
          > >
          > > I don't know. I read your replies a bunch of times I see what you're
          > > saying - but I'd like a little more convincing that injecting a
          > > repository into a domain object is a good idea.
          > >
          > > Here's my problem - I am fully aware that the repository abstracts
          > > away the persistence layer, and that no matter what, the domain will
          > > never know anything about SQL, XML, in-memory, etc... but I still
          > > have issue with the domain object even knowing to access a
          > > repository. Back to my currency example - a Currency object should
          > > know how to convert Money to another type of Money based an exchange
          > > rate (i.e., USD to Euro at a 1.4% exchange rate)... I think the
          > > logic to go into a repoistory and look up the currency exchange rate
          > > is OUTSIDE of the scope of the responsibility for a Currency object.
          > > Many times when repository access is needed, different objects need
          > > to be retrieved and other things outside of the scope of the object
          > > have to happen. It's dangerous to start saddling domain objects with
          > > the responsibility to access a repository and look things up, I
          > > think - because they should understand how to interact with each
          > > other in a world objects simply exist. HOW they come to exist (i.e.,
          > > from a repository) should be in the Service Layer - I think.
          > >
          > > But I am open to other opinions.
          > >
          > > In particular Roger - I'm curious about your experience with a
          > > service layer. Can you give a concrete example of how you did
          > > things, and more specifically, how adding simple functionality
          > > was "painful?" This would go a long way to seeing if I'm wrong about
          > > this whole Currency/Account thing.
          > >
          > > D
          > >
          >
        • Sergio Bossa
          ... Roger, I d be interested in knowing why you say that the ONLY solution is that aggregate A uses the aggregate B repository to retrieve a root object for
          Message 4 of 22 , Sep 30, 2006
            On 9/29/06, Stasko, Roger <Roger.Stasko@...> wrote:

            The thing I like about the repository pattern is spells out the relationship between aggregates.
             
            If aggregate A (invoice, for example) needs access to aggregate B (order, for example), then the ONLY solution is that aggregate A uses the aggregate B repository to retrieve a root object for aggregate B. 

            Roger, I'd be interested in knowing why you say that "the ONLY solution is that aggregate A uses the aggregate B repository to retrieve a root object for aggregate B". Why can not aggregate A directly hold a reference to aggregate B?

            Thanks,
            Cheers,

            Sergio B.

            --
            Sergio Bossa
            Software developer and analyst, blogger and Open Source enthusiast.
            Blogging on: http://sbtourist.blogspot.com
          • Sergio Bossa
            ... +1 I always use a Service Layer in my projects. Other than providing a place for allocating external responsibilities like you say, I find it invaluable
            Message 5 of 22 , Sep 30, 2006
              On 9/29/06, Randy Stafford <randy.stafford@...> wrote:

              In my experience as an architect of enterprise applications, I've seen certain typical responsibilities – notification of stakeholders (including other systems) that an event has occurred, control of transactions, interaction with external systems, initial access of domain objects, etc. – that I just don't feel are appropriate to allocate to the domain layer, based on some vague romantic notion of reusability, separation of concerns, etc.

              In the end it's all about allocation of responsibility, and I acknowledge it's somewhat of an art, with different styles and preferences.  Over the years my idealism has given way to pragmatism to some extent.  But when I build systems I still view service layers and domain layers as complementary, and I don't mind at all letting domain objects depend on repositories.


              +1
              I always use a Service Layer in my projects.
              Other than providing a place for allocating "external" responsibilities like you say, I  find it invaluable for providing a coarse grained use case driven interface to clients.

              Cheers,

              Sergio B.

              --
              Sergio Bossa
              Software developer and analyst, blogger and Open Source enthusiast.
              Blogging on: http://sbtourist.blogspot.com
            • Udi Dahan
              Maybe the title of this thread should be updated. So why is the idea that a domain object should even know there exists a repository of other domain objects
              Message 6 of 22 , Oct 1, 2006

                Maybe the title of this thread should be updated.

                 

                So why is the "idea that a domain object should even know there exists a

                repository of other domain objects" against DDD?

                 

                I wouldn’t say it’s against DDD, but that it comes from a sense of aesthetics of design.

                 

                As far as I can tell, this idea doesn't come from Eric's book, nor does

                it appear in Fowler's PofEAA book.

                 

                You’re right.

                 

                The justification for this idea suggests that we need to bend over

                backwards to enable some small aspect of our application to be

                independent and interchangeable. Now, if there is a specific business

                requirement that makes this important that is one thing. But I don't

                care for the idea of doing this in the pursuit of design purity.

                 

                I wouldn’t go so far as to say “bend over backwards”, and we’re talking about the core logic of the system here, not “some small aspect”.

                 

                One of the refreshing things about DDD is the notion of bounded contexts

                and pragmatic modeling (use modeling to solve application problems not

                to produce "pure" designs). What we're trying to accomplish is to build

                a sensibly-designed, coherent working application within a specific

                bounded context. By properly identifying our aggregates and effectively

                using repositories to keep those aggregates independent of each other

                we've gone a long way to creating a robust application.

                 

                What does you mean to keep “those aggregates independent of each other”? What this means to me is that domain objects from one aggregate would not be involved in the same graph as those from a different aggregate – for instance, if Employee is in one aggregate, and Customer and Order are in another, the following code would not appear:

                 

                myEmployee.Customers

                or

                myEmployee.Orders

                 

                However, the class Employee could still be aware of the other two classes – contain methods that accept them as parameters.

                 

                Anyway, this is what’s been working for me.

                Hope it helps.

                 

                 

                Udi Dahan - The Software Simplist

                .Net Development Expert & SOA Specialist

                 

                email:   Udi@...

                mobile:  +972-(0)522-888-426

                web:     http://www.UdiDahan.com

                connect: LinkedIn

                 

                Microsoft Solutions Architect MVP

                 

                 

                Microsoft Israel Certified .Net Expert

                 

                           

                 

                 


                --
                No virus found in this outgoing message.
                Checked by AVG Free Edition.
                Version: 7.1.405 / Virus Database: 268.12.9/458 - Release Date: 27/9/2006

              • paul_gielens
                Consider the following example (borrowed from DDD). It is to my belief that repositories are part of the domain, and thus Domain Objects may depend on
                Message 7 of 22 , Oct 1, 2006

                  Consider the following example (borrowed from DDD).

                  It is to my belief that repositories are part of the domain, and thus Domain Objects may depend on repositories. Both of the following implementations are valid.

                  public class Car
                  {
                    .. 

                    public void StartEngine()
                    {
                      Engine.Start();
                    }

                    public Engine Engine
                    {
                      return engineRepository.ForCarId(id);
                    }
                  }

                  or

                  public class Car
                  {
                    ..

                    public void StartEngine()
                    {
                      Engine v6 = engineRepository.ForCarId(id);
                      v6.Start();
                    }
                  }

                  Any thoughts?

                  Kind regards,
                  Paul Gielens
                  http://weblogs.asp.net/pgielens

                • Stasko, Roger
                  A can certainly hold a reference to B; but I was thinking about the original context of this thread -- that A and B were independent aggregates. Or perhaps
                  Message 8 of 22 , Oct 2, 2006
                    A can certainly hold a reference to B; but I was thinking about the original context of this thread -- that A and B were independent aggregates.  Or perhaps that was a bad assumption?


                    From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Sergio Bossa
                    Sent: Saturday, September 30, 2006 3:22 AM
                    To: domaindrivendesign@yahoogroups.com
                    Subject: Re: [domaindrivendesign] Re: Accounts and Members

                    On 9/29/06, Stasko, Roger <Roger.Stasko@ libertymutual. com> wrote:


                    The thing I like about the repository pattern is spells out the relationship between aggregates.
                     
                    If aggregate A (invoice, for example) needs access to aggregate B (order, for example), then the ONLY solution is that aggregate A uses the aggregate B repository to retrieve a root object for aggregate B. 

                    Roger, I'd be interested in knowing why you say that "the ONLY solution is that aggregate A uses the aggregate B repository to retrieve a root object for aggregate B". Why can not aggregate A directly hold a reference to aggregate B?

                    Thanks,
                    Cheers,

                    Sergio B.

                    --
                    Sergio Bossa
                    Software developer and analyst, blogger and Open Source enthusiast.
                    Blogging on: http://sbtourist. blogspot. com

                  • ornot2006
                    Hi,Randy, I am a newbie on DDD. Even I can tell the difference between the Domain Service and Service Layer, I can not help myself to put many business logics
                    Message 9 of 22 , Oct 3, 2006
                      Hi,Randy,
                      I am a newbie on DDD. Even I can tell the difference between the
                      Domain Service and Service Layer, I can not help myself to put many
                      business logics into the domain services and eventually get some
                      things like this:

                      Service Layer
                      -------------------------------------------------------
                      |
                      Domain Service
                      |
                      Entity, Value Object,Factory,Repository




                      Most probably, the service Layer just simply delegates the
                      invocation to the domian service .


                      My confusion mainly come from the question: Whose responsiblity
                      is it to coordinate the domain object in order to fufill some
                      business rules since the Service layer should be kept very thin?

                      I am struggling with this very long and hope getting your helps.

                      Regards
                      OrNot






                      --- In domaindrivendesign@yahoogroups.com, "Randy Stafford"
                      <randy.stafford@...> wrote:
                      >
                      > Sure, I agree with that, and Eric says as much on p.105 -
                      "Services are
                      > a common pattern in technical frameworks, but they can also apply
                      in the
                      > domain layer".
                      >
                      >
                      >
                      > However that's not what I intended with Service Layer - "Defines an
                      > application's boundary with a layer of services that establishes a
                      set
                      > of available operations and coordinates the application's response
                      in
                      > each operation". A Service Layer, as I documented it, is
                      comprised of
                      > what Eric eloquently describes as "application services" on pp.106-
                      107.
                      >
                      >
                      >
                      > Nor, I dare say, are "domain services" what the Fusion Method
                      people
                      > intended with system interface in 1993 - "The interface of a
                      system is
                      > the set of system operations to which it can receive [sic] and the
                      set
                      > of events that it can output". Nor what Alistair Cockburn
                      intended with
                      > Application Boundary in 1995: "Define the user interface to be
                      outside
                      > the application proper. Make all functions of the application
                      > accessible through a program-driven interface. . [D]etermine the
                      > services of the application. Create a program-driven (not human-
                      driven)
                      > interface, on the assumption that one day the application will be
                      driven
                      > by a computer system. The UI is one of several drivers. All
                      functions
                      > of the application must be accessible to the driving system."
                      >
                      >
                      >
                      > This is one of those cases where a term (service) has multiple
                      distinct
                      > meanings, and we need to be clear about which meaning we intend
                      when we
                      > use the term in conversation. Domain services are distinct from
                      Service
                      > Layers comprised of application services. Both ideas are useful
                      and
                      > have their place, but should not be confused with each other.
                      >
                      >
                      >
                      > Best Regards,
                      >
                      > Randy
                      >
                      >
                      >
                      > ________________________________
                      >
                      > From: domaindrivendesign@yahoogroups.com
                      > [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of aabelro
                      > Sent: Friday, September 29, 2006 11:46 AM
                      > To: domaindrivendesign@yahoogroups.com
                      > Subject: [domaindrivendesign] Re: Accounts and Members
                      >
                      >
                      >
                      > I personally consider that there can be Services in a Domain. They
                      are
                      > not mutually exclusive. A Service usually provides, well,
                      naturally, a
                      > service to an object. It does not hold internal state, because it's
                      > purpose is to provide operations for other domain objects. It
                      > encapsulates operations which do not belong to a specific object,
                      > either because the service is useful to more than one object type,
                      or
                      > because it's something that should be separated from the object,
                      like
                      > the task of communicating to an external system.
                      >
                      > Abel
                      >
                      > --- In domaindrivendesign@yahoogroups.com
                      > <mailto:domaindrivendesign%40yahoogroups.com> , "Randy Stafford"
                      > <randy.stafford@> wrote:
                      > >
                      > > It's good that you're thinking about allocation of responsibility
                      > > <http://c2.com/cgi/wiki?AllocationOfResponsibility
                      > <http://c2.com/cgi/wiki?AllocationOfResponsibility> > ; I believe
                      that
                      > is
                      > > at the heart of object-oriented design. But I agree with Roger
                      that
                      > it'
                      > > s perfectly natural, and pragmatic, for domain objects to depend
                      on
                      > > repositories. I've written
                      > >
                      <http://tech.groups.yahoo.com/group/domaindrivendesign/message/2327
                      >
                      <http://tech.groups.yahoo.com/group/domaindrivendesign/message/2327>
                      >
                      > in
                      > > this forum about that before, as the topic comes up often.
                      > >
                      > >
                      > >
                      > > Regarding service layers, as the author of the pattern, first
                      let me
                      > > state that I began doing DDD in 1988 in Smalltalk without
                      knowing any
                      > > different, because that's just how Smalltalkers did things. Back
                      then
                      > > it was four-layer architecture
                      > > <http://c2.com/cgi/wiki?FourLayerArchitecture
                      > <http://c2.com/cgi/wiki?FourLayerArchitecture> > in single-tier or
                      > > fat-client/server systems, with nary a service layer in sight.
                      As I
                      > > mused on the four-layer architecture discussion page
                      > > <http://c2.com/cgi/wiki?FourLayerArchitectureDiscussion
                      > <http://c2.com/cgi/wiki?FourLayerArchitectureDiscussion> > , I
                      think the
                      > > advent of distributed object technology and n-tier architecture
                      > brought
                      > > about an evolution in allocation of responsibility which yielded
                      what
                      > I
                      > > conceived as a service layer. I began using the suffix "Service"
                      in my
                      > > software architectures in about 1997, in the context of CORBA
                      and RMI
                      > -
                      > > based projects.
                      > >
                      > >
                      > >
                      > > But the idea was neither new or mine; it's timeless. The Fusion
                      Method
                      > > people at HP were writing
                      > >
                      > <http://www.amazon.com/Object-Oriented-Development-Method-Derek-
                      Coleman/
                      > <http://www.amazon.com/Object-Oriented-Development-Method-Derek-
                      Coleman/
                      > >
                      > > dp/0133388239> about it ("system interface", "system operation")
                      in
                      > > 1993. Alistair Cockburn was writing
                      > > <http://www.amazon.com/Pattern-Languages-Program-
                      Design/dp/0201895277
                      > <http://www.amazon.com/Pattern-Languages-Program-
                      Design/dp/0201895277> >
                      > > about it ("application boundary") in 1995. And what are web
                      services
                      > > and SOA now but service layers accessed through web protocols and
                      > > messaging systems?
                      > >
                      > >
                      > >
                      > > With service layer it was never my intention to take anything
                      away
                      > from
                      > > DDD, and I regret that some people have interpreted a service
                      layer as
                      > > an alternative to a domain-driven design. If you look at my
                      example in
                      > > PoEAA, and how I articulated the pattern, you'll see that I
                      > > intentionally re-used the same example (Revenue Recognition)
                      from the
                      > > Domain Model pattern, and I intentionally did not move any
                      > > responsibilities from the domain model to the service layer.
                      Rather, I
                      > > added additional responsibilities that I don't feel are
                      appropriate to
                      > > allocate to the domain layer. In my experience as an architect of
                      > > enterprise applications, I've seen certain typical
                      responsibilities -
                      > > notification of stakeholders (including other systems) that an
                      event
                      > has
                      > > occurred, control of transactions, interaction with external
                      systems,
                      > > initial access of domain objects, etc. - that I just don't feel
                      are
                      > > appropriate to allocate to the domain layer, based on some vague
                      > > romantic notion of reusability, separation of concerns, etc.
                      > >
                      > >
                      > >
                      > > In the end it's all about allocation of responsibility, and I
                      > > acknowledge it's somewhat of an art, with different styles and
                      > > preferences. Over the years my idealism has given way to
                      pragmatism to
                      > > some extent. But when I build systems I still view service
                      layers and
                      > > domain layers as complementary, and I don't mind at all letting
                      domain
                      > > objects depend on repositories.
                      > >
                      > >
                      > >
                      > > Best Regards,
                      > >
                      > > Randy
                      > >
                      > >
                      > >
                      > > ________________________________
                      > >
                      > > From: domaindrivendesign@yahoogroups.com
                      > <mailto:domaindrivendesign%40yahoogroups.com>
                      > > [mailto:domaindrivendesign@yahoogroups.com
                      > <mailto:domaindrivendesign%40yahoogroups.com> ] On Behalf Of
                      > andrewryan1906
                      > > Sent: Friday, September 29, 2006 9:34 AM
                      > > To: domaindrivendesign@yahoogroups.com
                      > <mailto:domaindrivendesign%40yahoogroups.com>
                      > > Subject: [domaindrivendesign] Re: Accounts and Members
                      > >
                      > >
                      > >
                      > > Everyone,
                      > >
                      > > I don't know. I read your replies a bunch of times I see what
                      you're
                      > > saying - but I'd like a little more convincing that injecting a
                      > > repository into a domain object is a good idea.
                      > >
                      > > Here's my problem - I am fully aware that the repository
                      abstracts
                      > > away the persistence layer, and that no matter what, the domain
                      will
                      > > never know anything about SQL, XML, in-memory, etc... but I
                      still
                      > > have issue with the domain object even knowing to access a
                      > > repository. Back to my currency example - a Currency object
                      should
                      > > know how to convert Money to another type of Money based an
                      exchange
                      > > rate (i.e., USD to Euro at a 1.4% exchange rate)... I think the
                      > > logic to go into a repoistory and look up the currency exchange
                      rate
                      > > is OUTSIDE of the scope of the responsibility for a Currency
                      object.
                      > > Many times when repository access is needed, different objects
                      need
                      > > to be retrieved and other things outside of the scope of the
                      object
                      > > have to happen. It's dangerous to start saddling domain objects
                      with
                      > > the responsibility to access a repository and look things up, I
                      > > think - because they should understand how to interact with each
                      > > other in a world objects simply exist. HOW they come to exist
                      (i.e.,
                      > > from a repository) should be in the Service Layer - I think.
                      > >
                      > > But I am open to other opinions.
                      > >
                      > > In particular Roger - I'm curious about your experience with a
                      > > service layer. Can you give a concrete example of how you did
                      > > things, and more specifically, how adding simple functionality
                      > > was "painful?" This would go a long way to seeing if I'm wrong
                      about
                      > > this whole Currency/Account thing.
                      > >
                      > > D
                      > >
                      >
                    • Randy Stafford
                      There are no hard-and-fast rules; no one-size-fits-all prescription. Business rules is such a vague term. And there is context-dependency. In general, an
                      Message 10 of 22 , Oct 4, 2006

                        There are no hard-and-fast rules; no one-size-fits-all prescription.  “Business rules” is such a vague term.  And there is context-dependency.  In general, an application is responsible for protecting the interests of certain stakeholders, not least of which might be some business funding the development and operation of the application, whose “rules” are encoded in logic in the application.  That logic may be in method code of traditional domain object classes.  Or you might even implement classes modeling rules (I’ve done that), and let traditional domain object instances refer to instances of those classes.  You might have Strategy patterns, or Specifications.  You might even put some logic (e.g. duplicate identifier detection) “above” (or “below”) the layer of traditional domain object classes.  The easiest way to articulate rationale for responsibility allocation decisions is to talk about one real-life example at a time, instead of starting with generalities and claiming they apply.  But I’m not going to ask you to describe your real-life example, because that will take you some time to do, and I may not have time to answer.

                         

                        Best Regards,

                        Randy

                         


                        From: domaindrivendesign@yahoogroups.com [mailto: domaindrivendesign@yahoogroups.com ] On Behalf Of ornot2006
                        Sent: Tuesday, October 03, 2006 8:42 PM
                        To: domaindrivendesign@yahoogroups.com
                        Subject: [domaindrivendesign] Re: Accounts and Members

                         

                        Hi,Randy,
                        I am a newbie on DDD. Even I can tell the difference between the
                        Domain Service and Service Layer, I can not help myself to put many
                        business logics into the domain services and eventually get some
                        things like this:

                        Service Layer
                        ------------ --------- --------- --------- --------- -------
                        |
                        Domain Service
                        |
                        Entity, Value Object,Factory, Repository

                        Most probably, the service Layer just simply delegates the
                        invocation to the domian service .

                        My confusion mainly come from the question: Whose responsiblity
                        is it to coordinate the domain object in order to fufill some
                        business rules since the Service layer should be kept very thin?

                        I am struggling with this very long and hope getting your helps.

                        Regards
                        OrNot



                        --- In domaindrivendesign@ yahoogroups. com, " Randy Stafford "
                        <randy.stafford@ ...> wrote:

                        >
                        > Sure, I agree with that, and Eric says as much on p.105 -
                        "Services are
                        > a common pattern in technical frameworks, but they can also apply
                        in the
                        > domain layer".
                        >
                        >
                        >
                        > However that's not what I intended with Service Layer - "Defines an
                        > application' s boundary with a layer of services that establishes a
                        set
                        > of available operations and coordinates the application' s response
                        in
                        > each operation". A Service Layer, as I documented it, is
                        comprised of
                        > what Eric eloquently describes as "application services" on
                        pp.106-
                        107.
                        >
                        >
                        >
                        > Nor, I dare say, are "domain services" what the Fusion Method
                        people
                        > intended with system interface in 1993 - "The interface of a
                        system is
                        > the set of system operations to which it can receive [sic] and the
                        set
                        > of events that it can output". Nor what Alistair Cockburn
                        intended with
                        > Application Boundary in 1995: "Define the user interface to be
                        outside
                        > the application proper. Make all functions of the application
                        > accessible through a program-driven interface. . [D]etermine the
                        > services of the application. Create a program-driven (not human-
                        driven)
                        > interface, on the assumption that one day the application will be
                        driven
                        > by a computer system. The UI is one of several drivers. All
                        functions
                        > of the application must be accessible to the driving system."
                        >
                        >
                        >
                        > This is one of those cases where a term (service) has multiple
                        distinct
                        > meanings, and we need to be clear about which meaning we intend
                        when we
                        > use the term in conversation. Domain services are distinct from
                        Service
                        > Layers comprised of application services. Both ideas are useful
                        and
                        > have their place, but should not be confused with each other.
                        >
                        >
                        >
                        > Best Regards,
                        >
                        > Randy
                        >
                        >
                        >
                        > ____________ _________ _________ __
                        >
                        > From: domaindrivendesign@ yahoogroups. com
                        > [mailto:domaindrivendesign@ yahoogroups. com]
                        On Behalf Of aabelro
                        > Sent: Friday, September 29, 2006 11:46 AM
                        > To: domaindrivendesign@ yahoogroups. com
                        > Subject: [domaindrivendesign ] Re: Accounts and Members
                        >
                        >
                        >
                        > I personally consider that there can be Services in a Domain. They
                        are
                        > not mutually exclusive. A Service usually provides, well,
                        naturally, a
                        > service to an object. It does not hold internal state, because it's
                        > purpose is to provide operations for other domain objects. It
                        > encapsulates operations which do not belong to a specific object,
                        > either because the service is useful to more than one object type,
                        or
                        > because it's something that should be separated from the object,
                        like
                        > the task of communicating to an external system.
                        >
                        > Abel
                        >
                        > --- In domaindrivendesign@ yahoogroups. com
                        > <mailto:domaindrive ndesign%40yahoog roups.com> , "
                        w:st="on">Randy Stafford "
                        > <randy.stafford@ > wrote:
                        > >
                        > > It's good that you're thinking about allocation of responsibility
                        > > <http://c2.com/ cgi/wiki? AllocationOfResp onsibility
                        > <http://c2.com/ cgi/wiki? AllocationOfResp onsibility> > ; I believe
                        that
                        > is
                        > > at the heart of object-oriented design. But I agree with Roger
                        that
                        > it'
                        > > s perfectly natural, and pragmatic, for domain objects to depend
                        on
                        > > repositories. I've written
                        > >
                        <http://tech. groups.yahoo. com/group/ domaindrivendesi gn/message/ 2327
                        >
                        <http://tech. groups.yahoo. com/group/ domaindrivendesi gn/message/ 2327>
                        >
                        > in
                        > > this forum about that before, as the topic comes up often.
                        > >
                        > >
                        > >
                        > > Regarding service layers, as the author of the pattern, first
                        let me
                        > > state that I began doing DDD in 1988 in Smalltalk without
                        knowing any
                        > > different, because that's just how Smalltalkers did things. Back
                        then
                        > > it was four-layer architecture
                        > > <http://c2.com/ cgi/wiki? FourLayerArchite cture
                        > <http://c2.com/ cgi/wiki? FourLayerArchite cture> > in single-tier or
                        > > fat-client/server systems, with nary a service layer in sight.
                        As I
                        > > mused on the four-layer architecture discussion page
                        > > <http://c2.com/ cgi/wiki? FourLayerArchite ctureDiscussion
                        > <http://c2.com/ cgi/wiki? FourLayerArchite ctureDiscussion> > , I
                        think the
                        > > advent of distributed object technology and n-tier architecture
                        > brought
                        > > about an evolution in allocation of responsibility which yielded
                        what
                        > I
                        > > conceived as a service layer. I began using the suffix
                        "Service"
                        in my
                        > > software architectures in about 1997, in the context of CORBA
                        and RMI
                        > -
                        > > based projects.
                        > >
                        > >
                        > >
                        > > But the idea was neither new or mine; it's timeless. The Fusion
                        Method
                        > > people at HP were writing
                        > >
                        > <
                        href="http://www.amazon.com/Object-Oriented-Development-Method-Derek-">http://www.amazon. com/Object- Oriented- Development- Method-Derek-
                        Coleman/
                        > <
                        href="http://www.amazon.com/Object-Oriented-Development-Method-Derek-">http://www.amazon. com/Object- Oriented- Development- Method-Derek-
                        Coleman/
                        > >
                        > > dp/0133388239> about it ("system interface",
                        "system operation")
                        in
                        > > 1993. Alistair Cockburn was writing
                        > > <http://www.amazon. com/Pattern- Languages- Program-
                        Design/dp/020189527 7
                        > <http://www.amazon. com/Pattern- Languages- Program-
                        Design/dp/020189527 7> >
                        > > about it ("application boundary") in 1995. And what are web
                        services
                        > > and SOA now but service layers accessed through web protocols and
                        > > messaging systems?
                        > >
                        > >
                        > >
                        > > With service layer it was never my intention to take anything
                        away
                        > from
                        > > DDD, and I regret that some people have interpreted a service
                        layer as
                        > > an alternative to a domain-driven design. If you look at my
                        example in
                        > > PoEAA, and how I articulated the pattern, you'll see that I
                        > > intentionally re-used the same example (Revenue Recognition)
                        from the
                        > > Domain Model pattern, and I intentionally did not move any
                        > > responsibilities from the domain model to the service layer.
                        Rather, I
                        > > added additional responsibilities that I don't feel are
                        appropriate to
                        > > allocate to the domain layer. In my experience as an architect of
                        > > enterprise applications, I've seen certain typical
                        responsibilities -
                        > > notification of stakeholders (including other systems) that an
                        event
                        > has
                        > > occurred, control of transactions, interaction with external
                        systems,
                        > > initial access of domain objects, etc. - that I just don't feel
                        are
                        > > appropriate to allocate to the domain layer, based on some vague
                        > > romantic notion of reusability, separation of concerns, etc.
                        > >
                        > >
                        > >
                        > > In the end it's all about allocation of responsibility, and I
                        > > acknowledge it's somewhat of an art, with different styles and
                        > > preferences. Over the years my idealism has given way to
                        pragmatism to
                        > > some extent. But when I build systems I still view service
                        layers and
                        > > domain layers as complementary, and I don't mind at all letting
                        domain
                        > > objects depend on repositories.
                        > >
                        > >
                        > >
                        > > Best Regards,
                        > >
                        > > Randy
                        > >
                        > >
                        > >
                        > > ____________ _________ _________ __
                        > >
                        > > From: domaindrivendesign@ yahoogroups. com
                        > <mailto:domaindrive ndesign%40yahoog roups.com>
                        > > [mailto:domaindrivendesign@ yahoogroups. com
                        > <mailto:domaindrive ndesign%40yahoog roups.com> ] On Behalf
                        Of
                        > andrewryan1906
                        > > Sent: Friday, September 29, 2006 9:34 AM
                        > > To: domaindrivendesign@ yahoogroups. com
                        > <mailto:domaindrive ndesign%40yahoog roups.com>
                        > > Subject: [domaindrivendesign ] Re: Accounts and Members
                        > >
                        > >
                        > >
                        > > Everyone,
                        > >
                        > > I don't know. I read your replies a bunch of times I see what
                        you're
                        > > saying - but I'd like a little more convincing that injecting a
                        > > repository into a domain object is a good idea.
                        > >
                        > > Here's my problem - I am fully aware that the repository
                        abstracts
                        > > away the persistence layer, and that no matter what, the domain
                        will
                        > > never know anything about SQL, XML, in-memory, etc... but I
                        still
                        > > have issue with the domain object even knowing to access a
                        > > repository. Back to my currency example - a Currency object
                        should
                        > > know how to convert Money to another type of Money based an
                        exchange
                        > > rate (i.e., USD to Euro at a 1.4% exchange rate)... I think the
                        > > logic to go into a repoistory and look up the currency exchange
                        rate
                        > > is OUTSIDE of the scope of the responsibility for a Currency
                        object.
                        > > Many times when repository access is needed, different objects
                        need
                        > > to be retrieved and other things outside of the scope of the
                        object
                        > > have to happen. It's dangerous to start saddling domain objects
                        with
                        > > the responsibility to access a repository and look things up, I
                        > > think - because they should understand how to interact with each
                        > > other in a world objects simply exist. HOW they come to exist
                        (i.e.,
                        > > from a repository) should be in the Service Layer - I think.
                        > >
                        > > But I am open to other opinions.
                        > >
                        > > In particular Roger - I'm curious about your experience with a
                        > > service layer. Can you give a concrete example of how you did
                        > > things, and more specifically, how adding simple functionality
                        > > was "painful?" This would go a long way to seeing if I'm
                        wrong
                        about
                        > > this whole Currency/Account thing.
                        > >
                        > > D
                        > >
                        >

                      • colin.jack
                        This is the sort of approach we use too. I personally prefer to completely avoid accessing repositories from the domain classes, as far as possible. ...
                        Message 11 of 22 , May 3, 2007
                          This is the sort of approach we use too. I personally prefer to
                          completely avoid accessing repositories from the domain classes, as
                          far as possible.

                          --- In domaindrivendesign@yahoogroups.com, "andrewryan1906"
                          <andrew1906@...> wrote:
                          >
                          > And... another thing to clarify. I misspoke earlier - clearly,
                          > Repositories are part of the domain. What I meant to say is, they
                          > should not be part of the CORE domain. So if I'm building
                          recruiting
                          > object, the Candidate object should be able to:
                          >
                          > Candidate.Hire();
                          > Candidate.Fire();
                          > Candidate.RateLevelofInterest();
                          >
                          > but the candidate should NOT be able to:
                          >
                          > Candidate.MatchToJobs();
                          >
                          > I'm saying this because this requires access to the JobRepository,
                          > which IMO is outside of the core domain and a part of the
                          supporting
                          > domain. Thus, the method should read:
                          >
                          > Candidate.IsAMatchWithJob( Job jobTobeMatched )
                          >
                          > and there should be another, thin method OUTSIDE of the Core Domain
                          > that says:
                          >
                          > public void CandidateService.MatchToJobs( Candidate c )
                          > {
                          > IList jobs = new List();
                          > foreach( Job j in JobRepository.Singleton.GetAll() )
                          > if ( c.IsMatchWithJob( j ) )
                          > jobs.Add( j );
                          >
                          > return j;
                          > }
                          >
                          > That's what I mean by leaving all of the work in the core domain,
                          > EXCEPT the process of getting things from the repository.
                          >
                          > Thanks,
                          > Andrew
                          >
                        Your message has been successfully submitted and would be delivered to recipients shortly.