tag:blogger.com,1999:blog-882821950355432699.post4659857201007224136..comments2022-12-07T21:25:53.386+11:00Comments on Paul Batum: Domain Driven Design (the book)Paulhttp://www.blogger.com/profile/18224234643439645641noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-882821950355432699.post-36126836479415960152008-05-02T12:55:00.000+10:002008-05-02T12:55:00.000+10:00That's a nice review, Paul. The implementation of ...That's a nice review, Paul. The implementation of DDD is something which I still struggle with, however. I've played around with a few OR/M tools such as doodas and most recently LINQ.<BR/><BR/>The concept of persistence and scope of the unit-of-work is not easily implemented especially in a non-persistent medium such as web pages. Proper implementation of theories is extremely difficult, especially from someone who little experience in that area.<BR/><BR/>And yes, I wholeheartedly agree with this:<BR/>"As the level of abstraction rises however the gap between the implementation and the abstraction, naturally, increases. In simple terms this creates a lot more scope for things to go (or be done) wrong. "Alvin Yonghttps://www.blogger.com/profile/13397582325047020377noreply@blogger.comtag:blogger.com,1999:blog-882821950355432699.post-85680035928410674072008-04-24T03:49:00.000+10:002008-04-24T03:49:00.000+10:00Wonderful explanation Malcolm.Wonderful explanation Malcolm.Paulhttps://www.blogger.com/profile/18224234643439645641noreply@blogger.comtag:blogger.com,1999:blog-882821950355432699.post-65010600989005289702008-04-23T22:33:00.000+10:002008-04-23T22:33:00.000+10:00Good point.Good point.Andrew Moylanhttps://www.blogger.com/profile/15277166449214446604noreply@blogger.comtag:blogger.com,1999:blog-882821950355432699.post-79108479643771581742008-04-23T19:37:00.000+10:002008-04-23T19:37:00.000+10:00"My view is that books like Design Patterns exist ..."My view is that books like Design Patterns exist precisely because the abstractions therein naturally arise so frequently that it's worthwhile to pre-learn them so that they can be spotted more quickly, and implemented more effectively."<BR/><BR/>I couldn't agree more with you on this Andrew, but I think there's also a bit more to it.<BR/><BR/>I believe that the less abstract the concept, the simpler it is to learn and subsequently recognise. Some patterns are so obvious that they tend to emerge naturally. For example, I used decorators and what is now called the 'dependency-injection pattern' long before I had heard either term, simply because they were the most logical way of solving the problem at hand.<BR/><BR/>As the level of abstraction rises however the gap between the implementation and the abstraction, naturally, increases. In simple terms this creates a lot more scope for things to go (or be done) wrong. <BR/><BR/>A good example is the mapper and unit of work patterns as per the Fowler model. When developing a data driven application, it is logical to deduce that I will need some classes to return some data in the form of objects and that I will need some way of tracking change and submitting those changes back to the data store. The problem is that this requirement is so abstract that there's many, many different (and often appalling) ways of implementing it. In a long-winded way, this brings me back to DDD. Books like DDD and PEAA deal with the specifics of <I>highly</I> abstract patterns - that is they offer an (or more than one) implementation as well as providing a narrative that discusses the pros and cons of alternative approaches. <BR/><BR/>Basically, what I'm saying is that 'pattern' books about highly refined patterns (such as Design Patterns) very much are about being "spotting more quickly, and implementing more effectively,", books about more abstract patterns (unless they are useless) tend to focus far less on the spotting and far more on implementation.Malcolm Younghttps://www.blogger.com/profile/11060109670290978219noreply@blogger.comtag:blogger.com,1999:blog-882821950355432699.post-66293276897456191722008-04-23T18:00:00.000+10:002008-04-23T18:00:00.000+10:00Andrew, somehow I missed one of Malcolm's comments...Andrew, somehow I missed one of Malcolm's comments, now I follow.<BR/><BR/>This book *IS* a pattern book, but with a more specific problem domain.Paulhttps://www.blogger.com/profile/18224234643439645641noreply@blogger.comtag:blogger.com,1999:blog-882821950355432699.post-39024152097480799512008-04-23T17:27:00.000+10:002008-04-23T17:27:00.000+10:00I'm not familiar with all of them. That list was c...I'm not familiar with all of them. That list was cut-and-pasted from Malcolm's post.<BR/><BR/>I'm not too sure about "deriving" them from O-O per se. But I would say that, when trying to "find the classes" before the coding commences, abstractions like, say, Specification, do naturally arise.<BR/><BR/>My view is that books like Design Patterns exist precisely because the abstractions therein naturally arise so frequently that it's worthwhile to pre-learn them so that they can be spotted more quickly, and implemented more effectively.Andrew Moylanhttps://www.blogger.com/profile/15277166449214446604noreply@blogger.comtag:blogger.com,1999:blog-882821950355432699.post-53616414398754321802008-04-23T16:57:00.000+10:002008-04-23T16:57:00.000+10:00Andrew, where did you become familiar with the pat...Andrew, where did you become familiar with the patterns that you listed? Because you pretty much gave a quick rundown of the topics covered in the first half of the book. I agree with Malcolm, deriving those patterns naturally from OO is a pretty big ask.Paulhttps://www.blogger.com/profile/18224234643439645641noreply@blogger.comtag:blogger.com,1999:blog-882821950355432699.post-20589481637205026602008-04-23T15:46:00.000+10:002008-04-23T15:46:00.000+10:00Andrew,I kind of like your one liner and think it'...Andrew,<BR/><BR/>I kind of like your one liner and think it's pretty appropriate. I would question the second part of your post though - if you think that patterns as complex as specification and repository arise 'naturally' from OO then more power to you! Mere mortals like me however still benefit from the documentation and description of these patterns - Evans taught me an awful lot.Malcolm Younghttps://www.blogger.com/profile/11060109670290978219noreply@blogger.comtag:blogger.com,1999:blog-882821950355432699.post-60625799924799603932008-04-23T12:15:00.000+10:002008-04-23T12:15:00.000+10:00I should clarify something. I didn't mean non-prog...I should clarify something. I didn't mean non-programmers are meant to read the book. I meant that DDD involves non-programmers modelling their problems in an O-O like way. But out with the old.<BR/><BR/>The new: Based on your responses I'll change my one line summary to: "Think about all the aspects of your problem, not just the individual pieces of software, in an O-O-like way." Here I am thinking of "specifications, services, repositories, value objects, aggregates and responsibilities" as things that naturally arise from thinking in an O-O-like way.Andrew Moylanhttps://www.blogger.com/profile/15277166449214446604noreply@blogger.comtag:blogger.com,1999:blog-882821950355432699.post-13650354463249195492008-04-23T09:59:00.000+10:002008-04-23T09:59:00.000+10:00It's difficult to describe in a one-liner as OO an...It's difficult to describe in a one-liner as OO and DDD are not orthogonal concerns. I would suggest that the easiest way to desribe it would be that OO is concerned with classes, interfaces, inheritance etc. and their relationships, while DDD is concerned with OO patterns that can be used to develop a domain model such as specifications, services, repositories, value objects, aggregates and responsibilities. You can't simply say 'DDD minus OO' as DDD is built <I>on</I> OO, any more than you can talk about C# without talking about OO.Malcolm Younghttps://www.blogger.com/profile/11060109670290978219noreply@blogger.comtag:blogger.com,1999:blog-882821950355432699.post-70730864498626798362008-04-23T07:18:00.000+10:002008-04-23T07:18:00.000+10:00Ok so I didn't actually give you a one line summar...Ok so I didn't actually give you a one line summary of DDD minus OO.<BR/><BR/>How about:<BR/><BR/>"Common, useful patterns to apply when designing a domain model, from the basic design of object interfaces to managing large-scale structure."<BR/><BR/>Malcolm, care to weigh in on this? I didn't find this easy, and I'm not particularly satisfied with my answer.<BR/><BR/>(p.s. for the benefit of anyone else reading these comments, it was Malcolm that originally advised me to read this book)Paulhttps://www.blogger.com/profile/18224234643439645641noreply@blogger.comtag:blogger.com,1999:blog-882821950355432699.post-59021020016463803532008-04-23T07:11:00.000+10:002008-04-23T07:11:00.000+10:00Hey Andrew, thats a pretty good question.First of ...Hey Andrew, thats a pretty good question.<BR/><BR/>First of all, I don't consider DDD to be about "getting non<BR/>programmers to understand object oriented design". The relevant<BR/>audience for this book is programmers/architects, and MAYBE business analysts if<BR/>they are heavily involved in the modelling process.<BR/><BR/>I would say that some of the concepts the book discusses could be described<BR/>as "specialised OO", and could be discovered naturally by trying to apply good OO design to a particular problem. However the book also discusses plenty of concepts that map more closely to system design than to object oriented design. For example, the question of what to do if you have separate teams working on the same overall system - how can you effectively share the model or portions of it? What boundaries can you define to make the process easier? What do you do if two teams have developed separate models in isolation and it becomes necessary to merge or connect them? These sorts of problems don't really fall into the realm of OO design, and much of the latter half of the book discusses this sort of problem.<BR/><BR/>I think you could pull out examples in the book that simply make sense from a good OO design perspective, some other examples that don't really relate to OO, and a few more that are somewhere inbetween.Paulhttps://www.blogger.com/profile/18224234643439645641noreply@blogger.comtag:blogger.com,1999:blog-882821950355432699.post-58029873580893889242008-04-22T11:17:00.000+10:002008-04-22T11:17:00.000+10:00That is, your one-line summary of "DDD minus OO".That is, your one-line summary of "DDD minus OO".Andrew Moylanhttps://www.blogger.com/profile/15277166449214446604noreply@blogger.comtag:blogger.com,1999:blog-882821950355432699.post-45580540981633325672008-04-22T10:53:00.000+10:002008-04-22T10:53:00.000+10:00DDD strikes me as "Get people other than the actua...DDD strikes me as "Get people other than the actual programmers to understand O-O". I suppose it must be something more. What your one-line summary?Andrew Moylanhttps://www.blogger.com/profile/15277166449214446604noreply@blogger.comtag:blogger.com,1999:blog-882821950355432699.post-80985706758198218322008-04-22T10:35:00.000+10:002008-04-22T10:35:00.000+10:00Great review of a great book Paul.Great review of a great book Paul.Malcolm Younghttps://www.blogger.com/profile/11060109670290978219noreply@blogger.com