Women in Technology

Hear us Roar



Article:
  Wiring Your Web Application with Open Source Java
Subject:   Not a good template for building a domain layer
Date:   2004-04-13 08:02:07
From:   Groo
Nice job putting this article together, however this is a good example of what Martin Fowler recently described as an Anemic Domain Model:


http://www.martinfowler.com/bliki/AnemicDomainModel.html


By putting your business logic in your service layer, as opposed to your domain layer, you miss out on all the important benefits of OO for your business layer, and end up back in the procedural world.


Full Threads Newest First

Showing messages 1 through 8 of 8.

  • Not a good template for building a domain layer
    2004-04-13 12:15:45  while(true) [View]


    By putting your business logic in your service layer, as opposed to your domain layer, you miss out on all the important benefits of OO for your business layer, and end up back in the procedural world.



    "all the important benefits of OO" We are missing all of them. I'm not really seeing this. I read Martin's article and I'm still not really seeing what benefits I'm missing by having a service layer.

    Martin's article didn't give enough concrete examples to convince me that a service layer is a bad thing.

    Anyway great article! My 2 cents!
    • Not a good template for building a domain layer
      2004-04-13 12:31:34  Groo [View]

      Sorry, I didn't mean to imply a service layer is not a good thing. What I meant to say was that the business logic logic should be in the domain objects rather than in the service layer.

      In a simple example such as this it may not be as obvious, but as you get a more complex domain model it becomes more apparent. For example, even something as trivial as polymorphism is hard to take advantage of without a proper domain model.
      • Not a good template for building a domain layer
        2004-04-27 09:29:50  thlee [View]

        IMHO the separation of domain model and business logic
        has became an inevitable trend in most business application
        development.

        The reason is that domain model often refers to conceptual/ER model, which is essentially
        the data/bean objects. Thus persistence is part of the requirement of the domain objects.
        While ideally POJO is preferred for domain objects (like Martin and other OO purist wished for),
        in most cases they have been converted to accomodate the persistent layer
        such as EJB or other O/R mapping tool due to the persistence requirement.
        To embed business logic inside the domain model implies that
        more (non-bean)APIs will be added to the domain model and persistent layer specific
        transaction-handling logic will need to be coded inside the domain objects
        which will make the domain model and implementation even uglier.

        Thus, separating the domain object from the business logic does have some advantages:
        1. Cleaner domain model and implementation
        2. Stability of domain model on changing/different implementations of business logic
        3. Separation of concern (bean persistence and business logic are separated)

        Just my 2 cents.

        BTW, nice article and comments.
        • Not a good template for building a domain layer
          2004-04-28 12:53:42  gaoy [View]

          No DTOs (data transfer objects) are maintained. This may be feasible for certain type of domain models, such as without inheritance and polymorphism. If it is running on a rich client such as Swing or C#, or B2B through web services, I wonder one can avoid using DTOs. Are there frameworks facilitating management of DTOs?

          Very nice article, and good usage of Spring IoC for decoupling layers via interfaces.
          • Not a good template for building a domain layer
            2005-01-01 18:18:31  wrschneider99 [View]

            I stand corrected on my original comment;
            Hibernate does indeed let you persist private fields
            , and this feature can be used to move business rules into the domain layer when appropriate.

            Also, I have contributed to an XDoclet module to generate DTOs from metadata in the domain model, called XSnapshot.
        • Not a good template for building a domain layer
          2004-05-24 22:06:55  lachlanj [View]

          I see the domain layer & the service layer a little differently.

          Basically anything related to the problem domain, e.g. entities, value objects & the business rules related to them should go into the domain layer. This allows you to express domain concepts including business rules through objects.

          Anything related to the application (technical stuff) like transaction management, message sending, logging etc should not be in the service layer (sometimes application layer). This layer uses the domain layer to call the business rules. This layer can also be used to integrate with other applications.

          I think it is very important to make a clear separation between the two, after all they are two completely different things when you think about it. One is related to technical related implementation specific stuff, and the other is related directly to the problem domain in which the application is trying to solve.

          Without this separation it becomes too difficult to extend a system that has complex business rules and thus eliminates any of the benefits of using OOP.

          Check out http://www.domaindrivendesign.org/ for detailed information about why domain models are so important.

          Lachlan

          Lachlan
          • Not a good template for building a domain layer
            2004-05-24 22:09:50  lachlanj [View]

            Sorry, I meant to say...

            "Anything related to the application (technical stuff) like transaction management, message sending, logging etc should be in the service layer" :)
  • Not a good template for building a domain layer
    2004-04-18 05:43:01  wrschneider99 [View]

    Being in the procedural world is not necessarily a bad thing. The request-response aspect of web programming often lends itself more naturally to procedural than OOP methodology--otherwise, PHP, Python and Perl wouldn't be so successful.

    There are some practical obstacles to getting more benefits of OO (encapsulation in particular) inside domain objects. One is that Hibernate and other persistence layers force you to have setters for all properties and directly expose (untyped) collection instances. That makes enforcing any real invariants on the domain objects nearly impossible--for example a setter can't throw an exception if some business rule would be violated, because the rule depends on other properties that might not be loaded from the DB yet.

    Once I attempted to solve this problem by making richer domain objects that wrapped the "dumb" persistent state beans. But this breaks down when you have transactions that span multiple objects/tables (as most do!)

    There is a place for OOP in web applications but for transient domain/data objects constructed and thrown away in the scope of each request, the costs to get the benefits of OOP may outweigh the benefits.