Business Logic vs Domain Logic question

Discussions

EJB design: Business Logic vs Domain Logic question

  1. Business Logic vs Domain Logic question (4 messages)

    Ib EJB Pattern Design (p 129), Floyd Marinescu wrote:

    "There are two kinds of business logic, one that basically *is* domain logic, and one that does involve workflow that does not belong in the domain model (and thus lives in the services layer)."

    The way I interpret this is:

    1) An entity in the domain layer should never have to create or delete another entity because this kind of workflow belongs in the Services layer. An example of this is the TSS's Forum and Message entities: The Forum is not responsible for creating the Message, It's the facade bean (in the services layer) that creates the Message and passes it to the Forum's postMessage method.

    2) There should be as less interactions as possible between entities in the domain layer.


    Do you agree with this interpretation?

    T.
  2. Hi,

    This is interesting as I have recently had thoughts and discussions about this with my fellow developers.

    I think firstly your interpetation of the design is correct. However IMHO I am not sure I agree with the design, especially with regards this example. Since the message is dependent on the forum I would have the Forum EJB create the message.

    That aside I think the whole area between business logic v domain logic is very grey. A better example of how grey it is can be found if you started to charge for posting messages. If you implemented this I could see two design options,

    (i) The Session Facade would call a method on the forum EJB to post the message (postMessage). The session facade would then call a method on an account EJB to charge the account. This could be considered a very procedural/workflow approach to design.

    (ii) The Session Facade would call a method on the forum EJB to post the message postMessage. Inside the forumEJB postMessage the account EJB would also be looked up and the user charged. In my mind a more classic OO design approach where business behavour lives completely on the domain objects.

    I personally struggle between (i) and (ii) a lot. I mainly implement (i) as it is an understood approach, however I still can not convince myself that this is the 100% right thing to do.

    David
  3. David,

    If the forum creates the message, the forum's postMessage method must then mirror the Message's constructor (i.e. same signature). This introduces an unnecessary coupling between these two entities.

    Regarding your second point, I'm not convinced that (ii) is more OO as it would force you to add non forum-related logic in the forum (if, for instance, you must charge only a certain category of posters,) and thus break the encapsulation.

    However, the risk I see is if we push this logic too far, we end up with objects that have just data and service objects that handle the business logic (i.e. instead of file.exists(), you'd have FileManager.exists(file)).



    T.
  4. Hi,

    "If the forum creates the message, the Forum's postMessage method must then mirror the Message's constructor (i.e. same signature). This introduces an unnecessary coupling between these two entities. "

    Why would you not use Value Objects/DTO's and that way your signature is not coupled at all? I could also argue that the message is dependent on the Forum so these objects are coupled together. In the end I think this is a bad example for a reason for a service layer.

    "Regarding your second point, I'm not convinced that (ii) is more OO as it would force you to add non forum-related logic in the forum (if, for instance, you must charge only a certain category of posters,) and thus break the encapsulation."

    Encapsulation does give a good argument for a service layer in this charging for an post example.

    "However, the risk I see is if we push this logic too far, we end up with objects that have just data and service objects that handle the business logic (i.e. instead of file.exists(), you'd have FileManager.exists(file)). "

    Totally agree! I have worked on systems where the Entity EJBs have been little more than database views and all the work is done in the service layer. It is an easy path to find yourself on.

    David
  5. "Totally agree! I have worked on systems where the Entity EJBs have been little more than database views and all the work is done in the service layer. It is an easy path to find yourself on."

    Yep, same here.
    I'd say that the Session Facade pattern encourages this type of design as it forces you to present a non OO view of you system (a bunch of services with methods that consume and produce DTOs). If you start by designing the service layer, it's tempting to keep this state of mind in the domain layer.

    Opinions?

    -T