Discussions

News: Domain Driven Design with Spring and AspectJ

  1. Domain Driven Design with Spring and AspectJ (4 messages)

    A tutorial on how to implement a Domain Driven Design (DDD) with Spring and AspectJ. Read how to use load-time weaving with Spring's and AspectJ's support in order to enhance your domain model. Check it out at the following URL:

    JavaCodeGeeks: Domain Driven Design with Spring and AspectJ

  2. What was the point of the article? Are they proposing to push persistence logic into POJO entity? If so I dont see much benefit to it and has been talked about since Booch times. 

    But I want comment on this sentence from the article.

    "Let’s face it, we are not OOP programmers, as everything we need are structures and procedures, invented fifty years ago. How many Java programmers are using inheritance and polymorphism in a day-to-day basis?"

    Yes, we are still writing structures and procedures because these are basic building blocks of any software component and have nothing to do with OOP-ness. What matters is how these structures and procedures are written and used. 

    1. With DOAs, services, controllers and so on they are done in service oriented way.

    2. What the article says is a something from the Booch school of though where object knows how to do everything such as persist or render itself.

    What is a better approach? I though it has been proven long time ago that Service Oriented approach proved to be superior and more flexible.

    And lastly on Domain Driven Design. There is no such thing as domain object because you cant statically define a domain. Domain is a variable set of interacting components that communicate with each other using some type of "structures" which in case of this article will be DAO entities, service transfer objects and controller models which are not and should not be the same object type.

     

     

     

  3. And lastly on Domain Driven Design. There is no such thing as domain object because you cant statically define a domain. Domain is a variable set of interacting components that communicate with each other using some type of "structures" which in case of this article will be DAO entities, service transfer objects and controller models which are not and should not be the same object type.

    I agree with you Tsolak, your first comment in TSS is circa 2001, so you are doing software during almost 10 years, good.

    The problem of this industry is the lack of HISTORY and MEMORY because of most of programmers are very young, because of this when anyone with some "reputation" like Fowler says "anemic models is an anti-pattern" everybody automatically says is that "anemic models" is "considered an anti-pattern", period, most of them don't know OOP is around 20 years old.

    Of course some basic business logic can be put on model, right, but the discussion of anemic models vs rich models reminds me the old optimistic glorification of Object Oriented Programming in the early days of the "invention". In these days people loved to put tons of code in the same class and adding tons of forced inheritance, all into the same hierarchy.

    Now we are in the opposite, almost nobody uses implementation inheritance because "someone" showed a stupid and simplistic example of bad use of implementation inheritance from a Java core class not designed for inheritance, then "implementation inheritance" is bad... crazy.

    The virtue is in the middle:

    * No, no, is a very bad idea to put service based code (persistence, remoting, UI code) into your domain classes

    * Anemic models are not anti-OOP, most of fields and methods of a data model MUST be public because we do MANY different things to them, encapsulation is not important in a domain model, inheritance and polymorphism are more important and can be used in anemic models. Said this, I use the full power of OOP in service objects, I use encapsulation, implementation inheritance, polymorphism most of the time in service objects, sometimes I use implementation inheritance in service objects not possible or forced in a data model.

     

     

  4. I really wish TSS would stop accepting articles from JavaCodeGeeks.  When are they useful/good?

  5. Actually, the article is not that bad. And there is credibility in DDD as a whole. Actually, the proposed approach is used in some places, and I've seen it not once. But I don't like it. Not because I don't like DDD, but because it violates a number of other practical points. I've written on the topic some time ago: http://techblog.bozho.net/?p=180