Announcement Announcement Module
Collapse
No announcement yet.
About business layer : manager and domain Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • About business layer : manager and domain

    Hello,

    I've read some interesting thread on this forum. Lot's of spring users agree that business domain "sub-layer" should not only include property objetc (objects with only get/set) but also business methods.
    Presentation layer should get business domain objects through a service sub-layer (business manager) that may use DAO or any other integration service to access persistant datas.

    It seems good to me to cut business layer into those two sub-layers. I just have a question : I don't know what 'business method' could be put into my domain object. I've set some "convenience" methods that compute attributes or map any 'internal' datas, but for any "functionnal" method I'd require access to other domain objets, and so use business managers to access DAO.

    I thing they're should not be such a dependency domain -> manager. Did I missunderstand the meaning of business method ?

    Any explaination would be welcome.

    Nico.

  • #2
    Re: About business layer : manager and domain

    Originally posted by ndeloof
    Hello,

    I've read some interesting thread on this forum. Lot's of spring users agree that business domain "sub-layer" should not only include property objetc (objects with only get/set) but also business methods.
    I also have troubles with where to place logic.

    It seems good to me to cut business layer into those two sub-layers.
    Hmmm... what layers do you have in mind? At the moment I`m thinking about a service layer that coordinates security/transactions. But with Spring the service layer is quite empty. And I`m thinking about business layer..

    But I`m irritated by the fact where to place the business logic. Should the be a service-method like approach.. reducing the domain object to data holders (see: http://www.martinfowler.com/bliki/An...mainModel.html)

    or should the logic be placed in the domain objects themselfs?

    And why not integrate the service layer and the business layer? If the service layer is empty (and no application logic is required) I see no need for this formallity.

    I just have a question : I don't know what 'business method' could be put into my domain object. I've set some "convenience" methods that compute attributes or map any 'internal' datas, but for any "functionnal" method I'd require access to other domain objets, and so use business managers to access DAO.

    I thing they're should not be such a dependency domain -> manager. Did I missunderstand the meaning of business method ?
    I have the same problem. I find it strange that I can`t find answers to my questions.. other people must encounter these problems in normal application almost the first day they are writing them. And that is why I`m asking myself the question: are there developers that write real business applications with Spring? Where do we can get answers to our questions?

    I have bought (and read) Patterns of Enterprise Applications, Domain driven design, J2EE Design and Development, and many other books. But there are still a lot of very important questions unanswered.

    Comment


    • #3
      I think you both got screwed by diffrent layer patterns.

      The most simple layer pattern is like:

      persistence layer <--> domain layer <---> presentation layer

      The persistence layer is about durability (how things get stored, database, filesystem etc.)
      The domain layer contains all business and model parts.
      The presenstation layer is about the interface to any user (wether biological systems (human, animals) or electronic systems (computer, reactive switches etc.))

      So to state your question clear, business+model is domain. What you like to refer to seams like a seperation between business and model and when to move business logic to model elements (like entities) and when to move the logic to business services.

      Well this is quite difficult to answer, but may be quite simple, too. One idea is to never rely on the value object pattern, when shaping entity (or model elements).

      Move allways as much logic (business logic) to the domain elements (entities) as you can. There are two distinction to this advise. First, the business logic is a suject of change (like policies etc -> rulebased business logic) and second, if the business logic requires a broader scope. Mostly a domain element /entity should not fiddle with transactions by itself, nor should it incooperate with elements from distant model parts (like a Person object negotiating with a traffic light object) or the business logic envolves extense operations on a variety of objects (extense sql-statements for example).

      So if it is about an object (setName, setParent, addChild, calculateTax) put it into the domain element, if it is about a collection of objects put it into the DAO (if it is related to the same kind of object) or put it into some business service objects if it is based on extens intercooperation between objects of various kind.


      Cheers,

      Martin (Kersten)

      Comment


      • #4
        Originally posted by Martin Kersten
        I think you both got screwed by diffrent layer patterns.

        The most simple layer pattern is like:

        persistence layer <--> domain layer <---> presentation layer

        The persistence layer is about durability (how things get stored, database, filesystem etc.)
        The domain layer contains all business and model parts.
        The presenstation layer is about the interface to any user (wether biological systems (human, animals) or electronic systems (computer, reactive switches etc.))

        So to state your question clear, business+model is domain. What you like to refer to seams like a seperation between business and model and when to move business logic to model elements (like entities) and when to move the logic to business services.
        This is one of my question. But sometimes there is an extra layer introduced between the data layer and the presentation layer: the application layer:


        The stack of layers.


        presentation layer
        ---------------------
        application layer (also the boundary for transactions and security)
        ---------------------
        domain layer
        ---------------------
        persitance layer.
        ---------------------

        The application layer (sometimes called the service layer/application layer I believe) is the boundary for transactions and security and also contains logic like sending email of and jms if something should be reported.

        I already wanted to integrate the application layer and the domain layer to a single layer.. I have more to do than writing empty classes.

        Well this is quite difficult to answer, but may be quite simple, too. One idea is to never rely on the value object pattern, when shaping entity (or model elements).
        How do you mean?

        Move allways as much logic (business logic) to the domain elements (entities) as you can. There are two distinction to this advise. First, the business logic is a suject of change (like policies etc -> rulebased business logic) and second, if the business logic requires a broader scope. Mostly a domain element /entity should not fiddle with transactions by itself, nor should it incooperate with elements from distant model parts (like a Person object negotiating with a traffic light object) or the business logic envolves extense operations on a variety of objects (extense sql-statements for example).

        So if it is about an object (setName, setParent, addChild, calculateTax) put it into the domain element, if it is about a collection of objects put it into the DAO (if it is related to the same kind of object) or put it into some business service objects if it is based on extens intercooperation between objects of various kind.
        Should a domain object have a reference to dao`s? THe layer on top could coordinate the transactions (I`m not afraid of this). But how (or if) should a domain object get a reference to a dao?

        Thanks for the information so far. I`m feeling a littlebit lost.. and I don`t like that.

        Comment


        • #5
          I don't buy the application layer anyways. Sending certain emails is also a matter of the domain for me - as long sending the certain email beging not related to the presentation layer of cause.

          What you might refer to, is the service layer. In fact the persistence layer is a special kind of a service layer (providing the services needed to persist data within a given resource (like a DB or the file system)). Service(s) layer(s) provide features your application (domain + presentation layer) may utilize to solve the task they are build for.

          I guess, this is more correct than using an application layer, which means abusing the word application. You know, the whole is referred as application so a part of it should not also pretend to be something like an application itself.


          > Well this is quite difficult to answer, but may be quite simple, too.
          > One idea is to never rely on the value object pattern, when
          > shaping entity (or model elements).

          How do you mean?
          There was an abuse going on, some years ago. You can still see the ripples of the abuse inflicting todays API designs. The root of all evil was called the Value Object pattern. Great, great harm was done by it (And I was part of the harm, too).

          This pattern is a result of the struct and union keywords of C++, I guess. People created structured unions of attributes and were much likely to continue this habbit, when moving to the object oriented world.

          A value object is something like this:

          realisation ValueObject {
          Object value;

          setValue(value) {
          this.value=value;
          }

          Object getValue() {
          return this.value;
          }
          }
          The object above does nothing else then storing a value. This is a great abuse of an object. Encapsulating attributes rather than logic is not a sufficient excuse for an object to exist. If you can not do something valuable, then you shouldn't exist in an object oriented world.

          Most of the early POJO and DAO implementations used this Value Object pattern. This resulted in strange systems with mixed responsibilities and a lack of cohesion.

          Should a domain object have a reference to dao`s? THe layer on top could coordinate the transactions (I`m not afraid of this). But how (or if) should a domain object get a reference to a dao?
          The problem is calling these objects DAO`s. I stoped thinking about them as DAO`s. Just think about what a DAO is doing. A DAO provides ways to interact with the persistance layer. So DAOs are only realisations of the task to mimic a repositiory of persisted objects. Since DAOs are mostly shaped by being responsible for a certain kind of object(s), it is natural that the DAOs get some kind of low level domain (business) logic.

          Short example:

          Objects to persist: Person and Offer
          POJOs: Person, Offer
          DAOs: PersonDAO, OfferDAO

          See each DAO is responsible for a sepcial kind of object indicated by the name of each DAO.

          The dao can (and should) implement some low level domain (business) logic like:

          PersonDAO.getPersonsByName(String namePattern) : Person []


          By changing the persistence scope from overlapping lifetime (application ends but persisted objects still exist) to included lifetime (application end means object ends) the name of the PersonDAO object would change.

          PersonDAO becomes PersonRepositiory or PersonRegistry. You see DAO isn't also a suiteable name. I have problems to clearly think about a person DAO. My current state of thinking is this:

          A PersonDAO is stateless and provides an interface/coupling to the persistence layer by providing CRUD methods for the managed POJO objects.

          It is more of a realisation than a real object. DAOs are an implementation detail and shouldn't be used outside of the domain layer. That's why I favour to hide the DAO as best as possible by refering to it as a service or at least build a service object (fascade) in front of it.

          By doing so, most of the work with DAOs became like a charm for me.

          When you start to add optimizations to your application everything starts to become more complicated. Than you will surely notice how high level business needs drip into the DAO objects making it clear, that the DAO objects just provide a static API entry point to abstract the interaction with the persistence layer.


          Cheers,

          Martin (Kersten)

          Comment


          • #6
            Originally posted by Martin Kersten
            There was an abuse going on, some years ago. You can still see the ripples of the abuse inflicting todays API designs. The root of all evil was called the Value Object pattern. Great, great harm was done by it (And I was part of the harm, too).

            This pattern is a result of the struct and union keywords of C++, I guess. People created structured unions of attributes and were much likely to continue this habbit, when moving to the object oriented world.

            A value object is something like this:

            realisation ValueObject {
            Object value;

            setValue(value) {
            this.value=value;
            }

            Object getValue() {
            return this.value;
            }
            }
            The object above does nothing else then storing a value. This is a great abuse of an object.
            There are two different definitions for value object.
            1) Someting like money: an object that doesn`t need an own identity. Most of the time value objects are immutable. (This is the definition of fowler and friends).
            2) Data Transfer Objects. Data transfer objects are objects to reduce netwerk traffic (so you won`t have chatty applications).

            I haven`t heard of your definition of value object. It looks like a simple wrapper.

            Encapsulating attributes rather than logic is not a sufficient excuse for an object to exist.
            I agree for 90%.

            Most of the early POJO and DAO implementations used this Value Object pattern. This resulted in strange systems with mixed responsibilities and a lack of cohesion.
            Yes.. and this is what I truly hate... My dear objects.. reduced to stupid records...

            A PersonDAO is stateless and provides an interface/coupling to the persistence layer by providing CRUD methods for the managed POJO objects.

            It is more of a realisation than a real object. DAOs are an implementation detail and shouldn't be used outside of the domain layer. That's why I favour to hide the DAO as best as possible by refering to it as a service or at least build a service object (fascade) in front of it.
            I agree that nobody from outside the domain layer should call doa`s.

            By doing so, most of the work with DAOs became like a charm for me.

            When you start to add optimizations to your application everything starts to become more complicated. Than you will surely notice how high level business needs drip into the DAO objects making it clear, that the DAO objects just provide a static API entry point to abstract the interaction with the persistence layer.
            You have solved the access to the dao`s by making them singletons?


            And I don`t have problems with dao`s. Only with the location of business logic. Should it be called in an entity or should it be placed in manager like objects?

            Comment


            • #7
              There are two different definitions for value object.
              1) Someting like money: an object that doesn`t need an own identity. Most of the time value objects are immutable. (This is the definition of fowler and friends).
              2) Data Transfer Objects. Data transfer objects are objects to reduce netwerk traffic (so you won`t have chatty applications).

              I haven`t heard of your definition of value object. It looks like a simple wrapper.
              I know the first one and the second as well. There an additional definition for the case I stated. It was not always considered for value objects to be immutable. Maybe there was a renaming going on. As far as I remember there was an additional referring to it as a State-carrying object. I don't know if this became a special pattern or was dropped because of its abuse of the OO principles.


              And I don`t have problems with dao`s. Only with the location of business logic. Should it be called in an entity or should it be placed in manager like objects?
              This is quite easy I guess. Put it to the objects if you can. If you have to incooperate uncompatible domain, meaning the object would need to call DAOs / advanced services to perform the task, than go for a service (or in your case a manager). The idea is to make the objects as smart as possible but not to smart that they deal with the whole picture they are a part of.

              -> A Catagory may deal with a product but should not deal with reviews. Something like the chain of responsibility but in a more semantic scense. (I thought I already said this? Huh)

              Can you give me an example which made you not sure where to put the logic?[/quote]

              Comment

              Working...
              X