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

RE: [domaindrivendesign] Repository Reference Inside an Entity?

Expand Messages
  • Stafford, Randy
    I believe that Repositories live ini the lower part of the domain layer, i.e. near boundary of the domain and persistence layers. And I believe it is
    Message 1 of 32 , Jun 7, 2005
      I believe that Repositories live ini the "lower" part of the domain layer, i.e. near boundary of the domain and persistence layers.  And I believe it is perfectly natural for domain objects to use Repositories to carry out their responsibilities, as I wrote in http://groups.yahoo.com/group/domaindrivendesign/message/2002.  These beliefs needn't preclude clients of the domain layer from using Repositories to access aggregate roots, and they needn't mean that Repositories are exclusively "above" the domain layer.
      As for how client code obtains a reference to a Repository it needs to use, that is an implementation detail.  Especially in the case of domain object methods, I would prefer not to pass Repositories as method parameters, or hold them in instance variables - that's just clutter.  I believe unit testing is facilitated easily enough by making Repository behavior polymorphable and by using a factory or broker idiom (perhaps injecting into the factory or broker the implementation on which to depend in the current execution).
      -----Original Message-----
      From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com]On Behalf Of Roni Burd
      Sent: Monday, June 06, 2005 10:48 AM
      To: domaindrivendesign@yahoogroups.com
      Subject: RE: [domaindrivendesign] Repository Reference Inside an Entity?

      I must admit I’m confused with Eric’s reply. I was in the belief that Repositories are a domain concept and thus could be used from the domain the same way I can use another entity, specification, service. I think most people tend to them focus on implementation details. The discussion then seems to shift into whether Repositories are DAO’s or not and so on and so on. For me repositories are model concept, and then there is RepositoryImplementation that is a different thing. In the discussion of how to implement it, I use a type of custom IoC (.Net doesn’t have Spring yet L ) to inject the actual RepositoryImp. This even gives me the ability to do unit testing.


      I must admit I don’t see any fault in using repositories form my Entities. I see this behavior when I do validation of entities mostly. Using repositories for Lazy-loading purposes is probably wrong. Eric’s book opened my eyes to the fact that software IS the model, the rest is just a shell for the user to see it (view) or for the system to save it (DAO, DAC,etc).


      I would really would like others opinion on this. If your view is that the client (let’s call the Fa├žade to the system, or Service) has to call repositories either to validate an object or other purposes then I’m totally confused. How can I achieve a rich domain model if I end having some business logic spread out in Services “above” the model?


      Sorry for my frustration tone, but I need to see the light J !




      From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of cyboc
      Sent: Monday, June 06, 2005 12:26 PM
      To: domaindrivendesign@yahoogroups.com
      Subject: [domaindrivendesign] Repository Reference Inside an Entity?


      Below is my question and Eric Evans' answer regarding whether you
      should have a repository reference inside an entity. I hope the answer
      is helpful to other designers.

      For Spring Framework users, I also created a similar discussion on
      Spring's Forum: http://forum.springframework.org/viewtopic.php?t=5918.
      Note that in that discussion I replaced the word "Repository" with
      "DAO". In my mind they are quite similar but Spring Framework users
      tend to prefer the term DAO.

      Joe.Kelly wrote:

      >Thanks for your great book "Domain Driven Design"!
      >I have a question about the refactoring you did on pages 177-178.
      >To refresh your memory, you refactored DeliveryHistory's collection
      >of HandlingEvents into a query by creating a
      >HandlingEventRespository. However, from looking at figure 7.6 and
      >reading the surrounding text, one aspect of this refactoring was
      >unclear to me -- which object holds the reference to
      >HandlingEventRepository (Cargo, DeliveryHistory, or Cargo's client)?
      >Joe Kelly
      >"All your bean are belong to us" - Spring Framework's IOC Container


      Very good question. Generally, I do not like model objects to
      reference repositories, so my answer would be, generally, the client.
      The client might look it up based on a well-known name, or you might
      use dependency injection.

      In effect, the repositories form a layer just above the model
      objects. They obviously must be above the model objects since their
      primary purpose is to obtain references to those objects and pass them
      to requestors. It would not be obvious that they would be above *all*
      model objects (rather than just above their own), but I find it works
      better. Repositories are edging into application functionality rather
      than model. You could view them as service access to the model

      I hope this helps.

      By the way, this kind of question would be appreciated on the
      domaindrivendesign Yahoo Group. I also prefer that they be posted
      there when the answer may be of interest to many people (as in this

      I'm glad you are enjoying the book.


    • ryzamm
      How about if only giving fetching operation on Repository to Domain object?.. That s mean we need to make sure Add,Update and Remove are restrict to use from
      Message 32 of 32 , Jun 11, 2006
        How about if only giving fetching operation on Repository to Domain
        object?.. That's mean we need to make sure Add,Update and Remove are
        restrict to use from Domain.

        Normally we need to have Repository reference coz we need some late
        information data from DB.. and i also quite interested to know how
        this problem can be handle with Specification Pattern. As we know..
        in Eric's book..that are posibble for Specification to use Repository


        --- In domaindrivendesign@yahoogroups.com, Dmitriy Kopylenko
        <dkopylen@...> wrote:
        > Roni Burd wrote:
        > > Is calling a Repository from a Specification ok, and are
        > > specifications at the same level as Repositories?
        > >
        > >
        > >
        > > If so can why can I use specifications form entities and not
        > > repositories?
        > >
        > >
        > >
        > > ------------------------------------------------------------------
        > I believe it is perfectly OK to have Specifications to be
        > with Entities. The are (Specifications) domain concepts, after all.
        > give a small (simplified) example from the project I'm currently
        working on.
        > There is an entity called "Course" and a so called
        > "OpenGradingPeriodSpecification" with "isSatisfiedBy(Course)" API,
        > associated with each Course entity. The configuration data for all
        > open periods (specs) is loaded in the database (it is based on the
        > course and the semester associated with the course). So, somehow I
        > to "cache" this data in the spec and "inject" it into each instance
        > the Course. So I've created a Map based implementation of the spec.
        > also created an "OpenGradingPeriodSpecRegistry" to expose
        the "cached"
        > spec and jdbc-based implementation which I configure in the Spring
        > ctx. so then I could freely inject it into "interesting parties".
        > such "interested party" is my "service layer" object that controls
        > creation of entities. In the case of the Course entity, it further
        > delegates to the CourseFactory.
        > So let's say we have:
        > CourseService.createCourse(...bunch of course pieces, some other
        args...) {
        > //.... some code...
        > //Inject the spect into each course via the spec registry
        > Course course = CourseFactory.newCourse
        > this.openGradingPeriodSpecRegistry.getOpenGradingPeriodSpesification
        > return course;
        > }
        > To some up, I usually (that's my style) *do not* associate
        > "Repositories" directly with "Entities", but rather configure them
        > style and dep. inject them into my "Service layer" (use case
        > controllers) where the implementation collaborates with them (gets
        > necessary data) an further delegates to "Entity factories" if
        > And also, I treat Specs as my core domain concepts and I *do*
        > Specs with Entities.
        > Regards,
        > Dmitriy.
      Your message has been successfully submitted and would be delivered to recipients shortly.