Announcement Announcement Module
Collapse
No announcement yet.
2005 all over again - domain driven design, where are we? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • 2005 all over again - domain driven design, where are we?

    With the coming of Erik Evans book 'Domain driven design' a lot of posts were made about how to do this in Spring.

    As even I started one back in 2005 (http://forum.springframework.org/sho...+driven+design) I was wondering if some of us actually tried to implement DDD? Or are we still where we were in 2005?

    So, share you experience, get the discussion lively again. That way I hope I don't have to post in 2009 ' 2007 again - domain driven design, where are we? '

    It seems I start looking for DDD each time my contractor jib is coming to an end, end especially when having implemented ANOTHER mvc application with an OpenSessionInViewFilter ... I still feel a lot of resistance from people I work with to get them thinking about DDD, is DDD still something mystical or have some of us really implemented something according to its 'ideas'?

    One thing that has never found a clear answer in the different Spring posts is: What about calling services or dao's from within a domain model?

    Hope hearing from ALL of you ;-)

    One thing I've noticed when scanning all the old DDD posts, where are the people behind Spring? What are their ideas? Because eventually they are the one writing down the Spring roadmap and getting things done ... so in 2007 I hope to hear more form them concerning this topic

    ps. Yes it seems that in a month or so I'm starting a new contracting job, this time using GWT, and I'm NOT going to use an 'OpenSessionInViewFilter' ;-)

  • #2
    Just started reading the book today - by pure coincidence - and will look forward to any discussions that arise on this forum

    Comment


    • #3
      I also agree this is a really interesting subject. Obviously with @Configurable, DI into the model is easy. However, most projects I have seen recently don't really get DDD or think it is important. I think this is really an issue of developers practicing it then rather than it making sense. Some of the developers do actually understand this and practice it. This does start to rub off on people, but it's all too easy to revert to old behaviour. Transaction script like behaviour is quick to develop (in the short term) and doesn't take much thought. DDD might be a better way of doing it, but people don't seem to be able to, or want to put the effort in. I don't I have worked on a project which had a real DDD, which is a shame.

      There still seems to be lots of confusion however about what a system using DDD should actually look like. As you said, should you inject services and daos into the domain model? Should the model have methods like save and delete? If you work with a good domain model maybe this makes these questions trivial, here's to hoping.

      Comment


      • #4
        Pros and Cons

        It is a difficult topic avoided by a lot of us, one of the reasons for this is that it can lead to massive postings trying to find the 'right' solution. But the fact is, in reality, there is no perfect solution for all kind of problems At the end of these discussions none of us are satisfied, but all feel a little bit disappointed. Even terminology seems to lead to confusion or sometimes frustration.

        So let's not start this topic with high hopes finding the right solution, but rather looking at each problem separately; discussing the pros and the cons of DDD and how it can be implemented with the current available technologies. Most of the time multiple solution can be agreed on. And perhaps ... if some of us feel up to it right down a DDD FAQ because so many questions seem to return on so many different forums.

        Those typically questions are:
        - What's the difference between a DAO and a Repository
        - Can your domain model access repositories, and to what degree (also save / delete?)
        - Which is the best layering technique (How does one layer in DDD?)
        - When applying DDD, should the domain objects be used in the views
        - Where can I find a simple Spring / hibernate based example using DDD techniques ... yes this last one is always a topic of frustration

        Well just something to get you started ;-)

        Hope hearing from you...

        Comment


        • #5
          Repository and/or DAO in DDD

          Originally posted by rebornspirit View Post
          - What's the difference between a DAO and a Repository
          Would love to hear if anyone has thought about the usage of Repository as Eric Evans has described in his classic book as opposed to DAO (or along with DAO), which we normally use in Spring based applications ..

          Cheers.
          - Debasish

          Comment


          • #6
            Originally posted by rebornspirit View Post
            As even I started one back in 2005 (http://forum.springframework.org/sho...+driven+design) I was wondering if some of us actually tried to implement DDD? Or are we still where we were in 2005?
            Hi rebornspirit,

            you know you're firing a very interesting yet complex discussion

            My answer is yes, since I started reading Evans' book I've tried to apply DDD principles in two real projects.

            In particular, I'm currently working at a big project for the Italian national broadcasting company (RAI), where I'm the lead Architect/Developer for the design and implementation of the domain architecture: here, we've applied a lot of DDD principles and I hope to find the time, as soon as it will reach the first public version, to write something about this really exciting experience.

            However, I can say you that it has been, and it is, a very hard work, because DDD helps you much in writing domain models that well support the business complexity, but it is something still new, and you often feel a bit like experimenting

            Moreover, even if I'm an active contributor of the DDD community through its mailing list, even if I've worked at some DDD based projects, I'm still learning and don't claim at all to be a DDD expert

            That said, here are some short answers to your questions:

            1 - What's the difference between a DAO and a Repository
            2 - Can your domain model access repositories, and to what degree (also save / delete?)
            3 - Which is the best layering technique (How does one layer in DDD?)
            4 - When applying DDD, should the domain objects be used in the views
            1 - Put in a simple way, the Repository is an object that sits in your domain, with a collection-like interface that can be directly used by your domain objects for having access to other domain objects. It encapsulates the real data access strategy, that can be implemented using normal DAOs.
            Why do not directly use a DAO?
            Putting it simple, because the repository has an interface modeled against the domain, while the DAO has a pure data access interface, and we can also use just one interface for all kind of DAOs in our application.

            2 - Yes, it usually can, and I have to say that it helps you solve many complex interactions involving object lifecycle management.

            3 - What do you mean, more specifically? Generally speaking, I apply pretty well the layering explained in the DDD book.

            4 - Yes, I think it must be used in all layers.

            I'd be glad to hear other opinions and other, more specific, questions.

            ps. Yes it seems that in a month or so I'm starting a new contracting job, this time using GWT, and I'm NOT going to use an 'OpenSessionInViewFilter' ;-)
            Why do you think MVC and OpenSessionInViewFilter are bad?
            DDD is not a matter of what view technology you use...

            Moreover, we are currently using Wicket and I'm literally missing SpringMVC ... Wicket is IMHO a real pain ... I hope GWT will be a better choice for you ... even if I don't think so!

            Cheers,

            Sergio B.

            Comment


            • #7
              Hi Sergio -

              Great to hear that u r working on a real life project which uses principles of Domain Driven Design.

              Originally posted by sbtourist View Post
              1 - Put in a simple way, the Repository is an object that sits in your domain, with a collection-like interface that can be directly used by your domain objects for having access to other domain objects. It encapsulates the real data access strategy, that can be implemented using normal DAOs.
              Why do not directly use a DAO?
              Putting it simple, because the repository has an interface modeled against the domain, while the DAO has a pure data access interface, and we can also use just one interface for all kind of DAOs in our application.
              Would love to hear ur opinions on the following :-
              1. Regarding your observations on repositories and DAOs, what is the level of granularity of repositories that u suggest ? I mean, DAOs usually have one implementation per database table, what about repositories ?
              2. In case I want to inject data access services within my domain object, should I inject repositories or DAOs ? I have been injecting DAOs with fairly good result - what is ur take on this ?

              Cheers.
              - Debasish

              Comment


              • #8
                View layer: DTO vs DDD

                Originally posted by sbtourist View Post
                Hi rebornspirit,

                you know you're firing a very interesting yet complex discussion
                I thought it would be to, looking at the number of postings it seems not to be such a hot topic. I have to admit, when you read the book written by Erik Evans you immediately think of 'yes, that's the way to go', but then you sit down behind your laptop and think ... 'what now?' ... because we are so used to writing anemic models - thank you EJB 1.0 specs for that - that too many questions begin to raise and causing the brain to short circuit :-D

                So it would be great if anyone could post some samples - small code snippets even - that give us something visual to discuss about.

                I hope to find the time, as soon as it will reach the first public version, to write something about this really exciting experience.
                I do hope the same ;-)

                Moreover, even if I'm an active contributor of the DDD community through its mailing list, even if I've worked at some DDD based projects, I'm still learning and don't claim at all to be a DDD expert
                Don't be so shy!!! :-)

                1 - Put in a simple way, the Repository is an object that sits in your domain, with a collection-like interface that can be directly used by your domain objects for having access to other domain objects. It encapsulates the real data access strategy, that can be implemented using normal DAOs.
                Why do not directly use a DAO?
                Putting it simple, because the repository has an interface modeled against the domain, while the DAO has a pure data access interface, and we can also use just one interface for all kind of DAOs in our application.
                A code snippet would really clarify what you exactly mean :-)

                4 - Yes, I think it must be used in all layers.
                I must say, I have been doing J2EE development for 5 years now, I have used domain models directly in the view layer (jsp, velocity, ...) and I have also used DTO's. And using the domain model in the view layer never gave me a good feeling. It works - yes it does, they both do - and in simple examples it looks really easy and natural to use domain models in your view layer. But when things begin to get complicated I prefer using DTO's, they are clean, simple and contain exactly what is needed. Let me give an example:

                - You need to show a search result page, a table with multiple rows and multiple columns
                -Too fill the columns of each result row data needs to be retrieved from multiple domain objects which are not associated with each other (no direct link)
                - Beside that other trivial (non domain object data) needs to be shown in columns, i.e. some calculated data or so...
                - Pushing all that information to a JSP or so really feels ugly, because in this case you still need a wrapper class that holds all the information needed to present a single row. So in this case you are using a wrapper which contains multiple domain objects and some trivial data ...
                - wouldn't it be cleaner to have a specific view model for that specific rsult page which only contains the necessary to be shown data?
                - And don't you hate it in a JSP or so when you type 'objectX.fieldY' and for some reason in time fieldY doesn't exist anymore crashing the system ... I know what refactoring is, but you must admit for non java related sources it does not always works 100%

                Why do you think MVC and OpenSessionInViewFilter are bad?
                DDD is not a matter of what view technology you use...
                I agree, it is not directly related to DDD, but I think it is one of the most used 'hacks' out there. It's not clean to keep the complete session open - but that my opinion, and many agree and many disagree... :-)
                But it would be nice to have some examples that show us how to use hibernate objects in JSP's with lazy loading but without the OSIVFilter.

                Moreover, we are currently using Wicket and I'm literally missing SpringMVC ... Wicket is IMHO a real pain ... I hope GWT will be a better choice for you ... even if I don't think so!
                Haven't used Wicket so can't elaborate on that one, but for the moment I'm very satisfied with GWT. And - yes - I have been using SpringMVC for 2.5 years, and I really loved it but I felt it was time for something new. Clients begin to understand that more and more is possible in the browser and are requesting more and more complex front end applications. Which leads us to ... JavaScript .... brrrrrr ... I think most of us felt the pain developing LARGE applications based upon JavaScript. In the end, you have a so much scripting in there that no one dares to touch it anymore, just keeping the fingers crossed that is does not break before your contract ends (the fun part of being a contractor lolz). I have used things like DOJO, DWR, other ajax and JavaScript libraries but at the end, especially after allll those years using JavaScript ... I said enough and tried out GWT and loved it. The ability to QUICKLY write very complex webapps ... and guess what being able to DEBUG your JavaScript front end has really been a blessing. Adding event handlers, layout containers, ... has never been sooooo easy. And yes, I'm using DTO's as a view model for my gui :-)

                In high level my app looks like

                GWT
                ---
                GWT-Spring view services inter connectors
                ---
                Spring business services
                ---
                Spring DAO + DB4O template (Spring modules)
                ---
                DB4O + Lucene

                This is also the very first time I'm giving an object oriented DB a try, Hibernate is cool but I think sometimes used in cases where it should better not have been used. We need to realize that RDBMS is not the only choice out there, using an OODMS relieves us from ORM hell :-) Or at least I hope it was a good decision... time will tell :-$

                It also feels more naturally using a OODMS when applying DDD, it just feels right you know hat I mean ;-)

                So ... it would be great if you could just post some small code snippets introducing us on how you are applying DDD

                Grtz

                Comment


                • #9
                  Ok I'll give it a try :

                  Originally posted by rebornspirit View Post
                  - What's the difference between a DAO and a Repository
                  I know this questions is discussed time and time again on the Domain-Driven Design book mailing list. Basically, the answer of the author which I can't find today is that the difference is mostly semantic : a repository express business concerns while DAO speak in term of data first. But behind the scene, they are implemented the same way. Proof :

                  Originally posted by http://www.infoq.com/articles/spring-2-intro
                  @Repository: Identifies a DAO object as representing the Repository pattern (in Domain Driven Design terminology). Spring 2.0 provides an aspect (PersistenceExceptionTranslationAdvisor) that can automatically convert technology-specific exceptions from objects annotated with @Repository into Spring's generic DataAccessException hierarchy.
                  Originally posted by rebornspirit View Post
                  - Can your domain model access repositories, and to what degree (also save / delete?)
                  If the objet needs to to fulfill its responsability than why not? For instance, a Command object should be able to access the ItemRepository. It's common sense. After all, repositories are part of the model. If you don't allow repository access in your domain model then you'll end up having very long services which equals programming procedurely (the famous anemic model).

                  What I disagree with is allowing an objet to save or delete itself to/from the repository. When you go this way, you give too much responsability to your class. Your class already have a responsability to take care of so why giving it another one, ie manage is own persistence. It violates the basic tenets of OO design so I would never do it.

                  Originally posted by rebornspirit View Post
                  - Which is the best layering technique (How does one layer in DDD?)

                  First of all, DAOs or Repositories implementations are part of the business layer. Why? Because they have dependencies on your businness objects. The persistence layer do exist but he's not implemented by any of us but frameworks as hibernate, Spring-JDBC or iBatis because none of these have a dependency on your domain model. Remember the basic rule of the layer pattern, a layer can't have a dependency on the layer above.

                  So here's the usual layers :

                  Presentation, UI : Usually split into 2 parts if you follow the MVC pattern, the View and the Input Controllers. This layer deals with the user which means getting its inputs using for instance a Struts action, a JSF event handler or a Spring controller and rendering back the response.
                  Frameworks examples :
                  JSF, Struts, Spring Mvc, ...

                  Application Controller (Optionnal)
                  Its main responsability is determining which services should be called and which view should be displayed back to the user. Usually it implies heavy state management. Personnaly, I haven't seen this layer implement but with new frameworks it'll be getting more common I guess.
                  Frameworks examples :
                  Spring Web Flop

                  Business : In my experience, usually divided in three parts. Facade, domain model and the repository implementation. Note that I think facade could be seen as a separate layer if you want but since it doesn't involve a lot of code I prefer to say it's in the businness layer. By the way, some people don't use facade and prefer to expose their complete domain model to the view. I don't know if there is a right answer to this one, both have issues which I won't detail here. As for the domain model, it is made of 5 types of objects usually according to DDD : Entity, Value Objects, the dreaded Services, Factories and Repositories.
                  Frameworks :
                  There isn't a framework telling you how to structure your businnes objects except EJB 2.x and that's really good because it's one of the main point of DDD. Business concerns are too specific and too volatile to be captured in a generic model. However, Spring does help you to deal with the cross-cutting concerns like transactions and security but doesn't tell you how to structure your classes. Finnaly, Hibernate and other persistence frameworks in combination with Spring DAO allows you to implement the repositories.

                  Persistance or integration (depending of the source):
                  As the name say, it's responsability is to handle the persistance of the domain model usually in relationnal database. You don't do anything.
                  Frameworks :
                  Hibernate, iBatis, SpringJDBC
                  (all 3 using Jdbc of course).

                  Originally posted by rebornspirit View Post
                  - When applying DDD, should the domain objects be used in the views
                  I'll pass on this one because there are too much issue to explain and I have to go back to work.

                  Originally posted by rebornspirit View Post
                  - Where can I find a simple Spring / hibernate based example using DDD techniques ... yes this last one is always a topic of frustration
                  Note I don't have any affiliation with the author but I recommend POJOs in Action by Chris Richardson. Explain all the issues mentionned.
                  Last edited by madtree; Feb 4th, 2007, 06:19 AM.

                  Comment


                  • #10
                    [QUOTE=rebornspirit;98169]It is a difficult topic avoided by a lot of us, one of the reasons for this is that it can lead to massive postings trying to find the 'right' solution. But the fact is, in reality, there is no perfect solution for all kind of problems At the end of these discussions none of us are satisfied, but all feel a little bit disappointed. *** Even terminology seems to lead to confusion or sometimes frustration. ***

                    Perhaps we need to develop a Ubiquitous Language for the domain driven design domain?

                    Comment


                    • #11
                      Originally posted by debasishg View Post
                      Regarding your observations on repositories and DAOs, what is the level of granularity of repositories that u suggest ? I mean, DAOs usually have one implementation per database table, what about repositories ?
                      Repositories have a different granularity than DAOs: there's usually one repository per aggregate root, because root entities are the only one with independent lifecycle, while other entities should be "saved" and "retrieved" through their relative root entities.

                      In case I want to inject data access services within my domain object, should I inject repositories or DAOs ? I have been injecting DAOs with fairly good result - what is ur take on this ?
                      I usually inject repositories, because:
                      1 - Their interface is expressed in terms of domain entities.
                      2 - They usually implement business behaviour that must happen when making CRUD operations.

                      However, repositories and DAOs can be implemented as the same object, i.e. using the Separated Interface pattern: so, what's your way of implementing repositories and/or DAOs?

                      Cheers,

                      Sergio B.

                      Comment


                      • #12
                        Originally posted by rebornspirit View Post
                        And using the domain model in the view layer never gave me a good feeling. It works - yes it does, they both do - and in simple examples it looks really easy and natural to use domain models in your view layer. But when things begin to get complicated I prefer using DTO's, they are clean, simple and contain exactly what is needed.
                        I've also worked at projects with both approaches: maintaing DTOs was a pain, while directly using domain objects was much cleaner.
                        However, this is my experience, and you can obviously disagree

                        It's not clean to keep the complete session open
                        Why do you say that?

                        Haven't used Wicket so can't elaborate on that one, but for the moment I'm very satisfied with GWT.
                        [CUT]
                        In high level my app looks like
                        [CUT]
                        This is also the very first time I'm giving an object oriented DB a try, Hibernate is cool but I think sometimes used in cases where it should better not have been used. We need to realize that RDBMS is not the only choice out there, using an OODMS relieves us from ORM hell :-) Or at least I hope it was a good decision... time will tell :-$
                        [CUT]
                        Regarding Wicket and GWT : it is true that they "easily" let you code complex UIs, but they have IMHO a great flaw : they make separation of concerns useless, forcing developers to produce a lot of Java code.
                        Regarding OODBMS vs RDBMS : your experiment sounds exciting: let us know how things go!

                        So ... it would be great if you could just post some small code snippets introducing us on how you are applying DDD
                        I'll surely post something in my blog, as soon as I'll have more time and energy.
                        I'll let you know.

                        In the meantime, let us go on with this discussion.

                        Cheers!

                        Sergio B.

                        Comment


                        • #13
                          Originally posted by rebornspirit View Post
                          I agree, it is not directly related to DDD, but I think it is one of the most used 'hacks' out there. It's not clean to keep the complete session open - but that my opinion, and many agree and many disagree... :-)
                          But it would be nice to have some examples that show us how to use hibernate objects in JSP's with lazy loading but without the OSIVFilter.
                          Well, we need to be careful with the distinction between "session" and "transaction" here. It's not clean to keep a business transaction open for view rendering purpose, but there is nothing wrong with keeping a hibernate session open until all the DB activities serving the same request are completed.

                          Comment


                          • #14
                            Originally posted by rebornspirit View Post
                            I must say, I have been doing J2EE development for 5 years now, I have used domain models directly in the view layer (jsp, velocity, ...) and I have also used DTO's. And using the domain model in the view layer never gave me a good feeling. It works - yes it does, they both do - and in simple examples it looks really easy and natural to use domain models in your view layer. But when things begin to get complicated I prefer using DTO's, they are clean, simple and contain exactly what is needed. Let me give an example:

                            - You need to show a search result page, a table with multiple rows and multiple columns
                            -Too fill the columns of each result row data needs to be retrieved from multiple domain objects which are not associated with each other (no direct link)
                            - Beside that other trivial (non domain object data) needs to be shown in columns, i.e. some calculated data or so...
                            - Pushing all that information to a JSP or so really feels ugly, because in this case you still need a wrapper class that holds all the information needed to present a single row. So in this case you are using a wrapper which contains multiple domain objects and some trivial data ...
                            - wouldn't it be cleaner to have a specific view model for that specific rsult page which only contains the necessary to be shown data?
                            - And don't you hate it in a JSP or so when you type 'objectX.fieldY' and for some reason in time fieldY doesn't exist anymore crashing the system ... I know what refactoring is, but you must admit for non java related sources it does not always works 100%
                            Here's some other post I wrote in responding to almost the same scenario presented to justify DTOs. On top of that, I'd say that, yes, it would be cleaner to have a specific view model, but that kind of cleanness should not come at the price of a fragile service API/implementation (unless justifiable by some significant performance gain). In other words, I would assemble the view model from DO's in my presentation layer, not the service layer - which makes it just a view model, not a DTO.

                            Comment


                            • #15
                              Originally posted by sbtourist View Post
                              Repositories have a different granularity than DAOs: there's usually one repository per aggregate root, because root entities are the only one with independent lifecycle, while other entities should be "saved" and "retrieved" through their relative root entities.
                              Very true.


                              Originally posted by sbtourist View Post
                              I usually inject repositories, because:
                              1 - Their interface is expressed in terms of domain entities.
                              2 - They usually implement business behaviour that must happen when making CRUD operations.

                              However, repositories and DAOs can be implemented as the same object, i.e. using the Separated Interface pattern: so, what's your way of implementing repositories and/or DAOs?
                              I also use injection of repositories for complex aggregates. But I must admit that for simple entities, I sometimes use the DAO directly. For complicated aggregates, repositories contain domain logic in addition to accessing the DAOs for data fetching purposes. And the contract for the Repository nicely abstracts away all these complications from the actual entity. From that point of view, ONE repository can *contain* MULTIPLE DAOs, each corresponding to the respective table in the database. And finally, I use interfaces as the contracts for repositories .

                              Cheers.
                              - Debasish

                              Comment

                              Working...
                              X