DDD Step By Step
A Practical Guide to Domain Driven Design

April 2009 - DDD on the Web

Sort by: Most Recent | Most Viewed | Most Commented

  • Strategic Design by Jérémie Chassaing

    I was looking yesterday at Eric Evans’ talk at the Øredev conference last November. You really should see it to understand better one of the most important part of the DDD book that is difficult to grasp on first reading. I’m currently working on a small company that had a problem with scaling their system. The existing system was working correctly but was going to stall in both performance and evolution perspectives. When we arrived, the plan of the preceding head of development was : ‘We need to restart from scratch, let’s specify everything, then code a clean version 2.0 in two years, and switch the legacy system off.’ Of course it was expected to fail. And even if it succeeded, after two years, they would have got the same software that two years before. It could be cleaner, but who cares ? When you’ve lost two precious evolution years, for a promising startup, count it as dog years . When we took control of the situation we planned the following : Extract the core business value of the software. Spot where you need new features. Develop new features as if it was in a clean environment. Develop anti corruption layers to hide the legacy system behind clean interfaces. This way you start to work on new business value now , you make...

  • Java vs .NET Developers by Greg

    Davy Brion has an interesting post discussing his recent interviews with .NET and Java developers . I have to say that I agree with some of his assessments. Much of what we discuss in .NET is far more common in Java as Java has a far healthier community than Microsoft. You will find terrible developers on both side but the terrible developers on the Java side have more mainstream exposure to good ideas than on the Microsoft side. The majority of the .NET community is fake as well, led by the leash by Microsoft. I remember in particular a discussion with quite a few people in Atlanta just after Katrina when I was there for a while where I was being laughed at and talked down to (the same tired arguments about sprocs)  for suggesting the use of an ORM, these are the same people who today will reiterate the same arguments and push themselves as “ORM experts”. How to we break out of this? I had great hopes for alt.net doing this but sometimes you feel like the engineer of a freight train who can see that truck 1/2 a mile ahead and has hit the breaks but is not hoping. I believe alt.net has at the least given the small few who were doing such things already a community upon which they can draw support from when they feel that they...

  • DDD: Videos from Øredev by Jack Charlton

    Leonard Petrica kindly pointed out that the videos from Øredev might be useful to those interested in Domain-Driven Design. They include talks from Jimmy Nilsson, Randy Stafford, Dan Berg Johnsson, Einar Landre and Eric Evans. So if you are interested, check them out Read More...

  • More on Repository by Greg

    Oren has since responded so let me in turn respond. Its something that we will never agree upon because we have been in such different contexts. He starts by saying First, careful re-reading of the actual post doesn’t show me where I said that the repository pattern is dead. What I said was that the pattern doesn’t take into account advances in the persistence frameworks, and that in many cases, applying it on top of existing persistence framework don’t give us much. I am sorry the exact statements were … “Repositories are a FAD" and “Repositories are the new Singleton”. I incorrectly used the term “dead” but the other statements are just as sensational to me. Of course I have already rebutted the argument that is being presented that it doesn’t take into account the “advances in persistence frameworks” by bringing up the fact that it represents a LAYER/TIER boundary in an architecture. To this Oren replies: Hm, I can see Greg’s point here, but I am not sure that I agree with him here. I would specify it differently .Service boundaries are procedural (be it RPC or message based, doesn’t matter). But a service spans both layers and tiers, and I am not going to try to create artificial boundaries inside my service. And yes, they...

  • MSDN Mag 6/2009 Editor’s Note Sneak Peak – On Aggregates by hdierking

    One new thing I want to start doing on this blog is releasing early drafts of my editor’s notes.  There are a couple reasons for this. I want my ednotes to start being more technical anyway, and you good folks are the right people to help ensure that Most of the early drafts are going to be too long to fit on the 1 page I’m allotted, so here you’ll get a sense of what I’m trying to say (and can possibly give me thoughts on how to cut it down) It gives me one more blog post per month :) At any rate, here’s the draft for the July issue’s note.  Enjoy… As you can see from the article lineup, we’re continuing our focus this month on issues related to software architecture with a subtle emphasis on how architectural decisions are impacted by the rise of cloud computing. And while it follow along those lines, I want to take advantage of this editor’s note to talk about something that I’ve spent some time thinking about recently – aggregates. Now, those of you who I have had the pleasure of getting to meet (or those of you to whom I am related) can attest to at least two things about me. Firstly, I’m always really excited to talk about software development – and software architecture in particular. Secondly, in such conversations...

  • Repository is Dead: Long Live Repository by Greg

    The title sums up the argument in Oren’s recent post about repositories . Although we have had some discussions on twitter about that post I wanted to offer people a bit more of an analysis of what he has said and the pros/cons of such a strategy. His post was originally intended to be an “alternative to the repository pattern” which he believes “is dead”. His new solution to the problem is to  instead use query objects that are passed into the repository to remove the "complexity”. Of course this is far from a new idea in fact it has been discussed on this blog in Specification or Query Object and also in some regard in The Generic Repository . The concepts are also discussed in Domain Driven Design itself (they are just called specifications instead of query objects). What is particularly annoying is the sensationalism associated with this post. It is extremely odd to argue against a pattern by suggesting to use the pattern eh? The suggested way to avoid the Repository pattern is to use the Repository pattern which shortening the definition he provided Provides the domain collection semantics to a set of aggregate root objects. So now that we have determined that he has not actually come up with anything new and is actually...

  • San Antonio community by Jason Meridth

    This list is for any developers in the San Antonio, TX area. These are the communities that are growing/starting that I've been involved (member/leader). If anyone knows of others please leave a comment and I'll update the post. (Man we love our Tuesdays in San Antonio, every Tuesday is a group meeting) Alamo Coders (organizer Phil Dennis ) http://www.alamocoders.net Welcome to Alamo Coders . We are a FREE San Antonio area IT professionals Users Group that focus on the tools, technologies, and programming languages that help a software developer/architect/manager in today's industry. If would like to learn more about software development or the tools that are involved in that process, or if you just want to learn more about what Alamo Coders has to offer the San Antonio area IT community, then please join our group. To get AlamoCoders Apparel, please go to our CafePress store. MEETINGS: 2nd TUESDAY OF EVERY MONTH (@ New Horizons) San Antonio Tech Book Club (organizer Anne Epstein ) http://groups.google.com/group/san-antonio-tech-book-club Our next meeting: Where: Skype When: 4/21/2009 (Tuesday) at 7pm Current Book: Implementing Lean Software Development: From Concept to Cash Topic: Chapters 1 & 2 NOTE: On 5/5/2009 we'll...

  • DDD Talk - Some more seats added by Yves Goeleven

    On June 16th I will be presenting a session on Domain Driven Design for the VISUG, the sessions was fully booked quite quickly... so I'm happy to hear that they have added more seats :) The talk will cover how DDD can be used as a pattern language. Secondly I will give you some real life design tips and tricks that will minimize the impact of refactoring during the life of your code. And finally I will give you some insights into how you can restructure your solutions so that you can focus on the most important parts. If you are interested in one of the available spots, sign up now ... Read More...

  • Back on Repositories and Paging. Introducing reporting. by Jérémie Chassaing

    I had quite a lot of comments on my previous post on repositories and paging , and there’s a lot of people coming from google looking for answers… It’s sign that there’s no good response to this issue now. The problem was how paging (a presentation concern) fits into a repository that should have only domain concerns… And the short answers is… It doesn’t fit ! It doesn’t mean you should forget everything I told you before but there’s a vision change. There’s something missing in DDD book… but present in current discussion about DDD. The book provides good building blocks (entities, repository…) but Evans says himself it has been a bit over emphasized . The book is mainly about maintaining and mutating your domain state, not about it’s presentation. CQS to the rescue The CQS (Command Query Separation) principle proposes to decouple Commands that change the state of the system, from Queries that ask the state of the system. The repository lies on the Command side, that’s why : It should be specialized to express only mutations that are possible for the system It should not expose presentation concerns like paging But what’s on the Query side ? The query side should be far more supple and provide tools to query the state of the domain...

  • Required developer reading by Jimmy Bogard

    The path from good developer to great developer is a long road, and not one with clear markers along the way.  When I started developing years and years ago, I was the fish floundering about, looking for the “Right” way of developing.  Most of this desire came from a innate feeling that I had no idea what the hell I was doing.  The first step I found from novice to expert was to acquire a depth, and breadth of knowledge on both how to write and how to deliver software.  I read a lot of books throughout the years, some good, some bad, and some indispensible.  Rather than come up with my own list, James Kovacs has an absolute perfect list: http://www.jameskovacs.com/blog/TheBookshelf.aspx If I could suggest a progression, it would be: Design pattern books Refactoring books Big Design (DDD, PoEAA) books Process books It’s rather pointless to jump into something like DDD if you don’t understand what the Strategy pattern is, or how to recognize and execute on the “extract method” refactoring.  These initial design and refactoring books are extremely important for a solid (ha ha) foundation, which the big design books build upon. After I studied these books, I looked back on the work I had done, and saw it very...