DDD Step By Step
A Practical Guide to Domain Driven Design

January 2009 - DDD on the Web

Sort by: Most Recent | Most Viewed | Most Commented

  • ALT.NET DDD Podcast by Udi Dahan

    I finally got around to listening to the alt.net podcast on domain driven design and heard Rob Conery telling about his experiences with DDD. I’ve met a fair amount of developers that went through a similar process and thought that I could help fix some of the common misconceptions that pop up when developers [...] Read More...

  • DDD & Many to Many Object Relational Mapping by Udi Dahan

    The ability to map entity relationships is broadly supported by many O/RM tools. For some reason, though, many developers run into issues when trying to map a many-to-many relationship between entities. Although much has already been written about the technological aspects of it, I thought I’d take more of an architectural / DDD perspective [...] Read More...

  • P&P - Web Service with REST Application Pattern by Colin Jack

    It was interesting that all the fuss over Oxite had a positive impact. Unfortunately Microsoft are also now giving us their views on REST (WCF REST starter kit, argh) and more recently REST with a domain model in Two-Tier Service Application Scenario (REST) which J.D. Meier calls the Web Service with REST Application Pattern . If you understand REST/DDD, or like Fowlers original meanings for his patterns, or believe that "Business Process Objects" with methods like "Promote (object[] data)" could be improved on then you might want to look away now. Come on though I've piqued your interest, have a look, it makes you feel dirty but yet at the same time makes you glad you now realize that perhaps there are other ways to build applications. Might be interesting to see how this relates to the old design documents MS used to pass out, pretty sure its not that different except resource is now used in some places instead of service. Service + procedural code + database, rock on. Anyway I'm going to go back to writing my own comments on it to put on the page, its going to take me a while... UPDATE : The contnet now indicates that it is up for community feedback (see comments) so its now up to us to provide useful...

  • Repositories and IQueryable, the paging case. by Jérémie Chassaing

    When it comes to repositories, people have a hard time figuring how to respect the DDD vision while taking most out of current ORM technologies (Linq and ORM) and not writing too much code – we’re so lazy. The war between IRepository<T> generic repositories or not is raging outside, and I took some time to chose my side. Here are the points to consider : The repository is a contract between the domain and the infrastructure The implementation details should not leak outside In my opinion, the first point indicates that the repository should be tailored to the domain needs . It cannot be generic, or it is not a contract at all. When writing a contract, details matter ! This doesn’t mean that we cannot use generic tools to access data behind the interface curtain. Linq DataContext and Tables<T> are very sharp tools to implement repositories. And there is a very good post by Greg Young about that. There is still a point to be discussed though : Should the repository methods return IEnumerable<T> or IQueryable<T> ? The IQueryable<T> is part of the framework, and cleanly integrated in the language. The problem is that its implementation depends heavily on the underlying provider. And it is a really serious...

  • DDD: The Generic Repository by Greg

    This discussion came up on the alt.net list last night and I had this post about half way done so I agreed to push it to the top of my stack and get it done for today given the timeliness of the information. I apologize that I lied about what the next post would be. I will have the follow up on the last DDDD post next. Consider the following code: Repository<Customer> repository = new Repository<Customer>(); foreach(Customer c in repository.FetchAllMatching(CustomerAgeQuery.ForAge(19)) { } The intent of this code is to enumerate all of the customers in my repository that match the criteria of being 19 years old. This code is fairly good at expressing its intent in a readable way to someone who may have varying levels of experience dealing with the code. This code also is highly factored allowing for aggressive reuse. Especially due to the aggressive reuse the above code is commonly seen in domains. Developers are trained that reuse is good and therefore tend towards designs where reuse is applied. The reuse can be seen two-fold. The first is in the definition of an IRepository<T> interface something like: interface IRepository<T> { IList<T> FindAllBy(IQuery<T> query); void Add(T item); void Delete...

  • DDDD: Master-Detail Question by Greg

    I received an interesting question via email recently that I figured would be better answered via a blog post than a private response. Greg, <clip of intro and flattery> So you are getting messages directly out of your repositories and sending command messages directly to them for persistence. There’s one thing that hit me when thinking about your approach: You do not seem to have a UI with a master-detail connected with this “model”, as it sounds very transactional. Further sending a bunch of messages just as dta for a single view does not make sense. Do you also have to deal with such UI stuff and how do you support it? I guess with another synced model? This is a great question as it really jumps into how things work architecturally. This becomes rather obvious in the talk I have been doing as there are diagrams but has not been talked about in detail on this blog. Command and Query Separation The first thing that should be discussed here is that repositories are not responsible for handling "read" messages. Repositories have a single reading operation and that is to load a single instance of an aggregate root based upon it's unique identifier. CustomerRepository::Get(Guid Id) This is because our domain is only...

  • Alt.Net - Januari meeting by Yves Goeleven

    This time we are going to discuss DDD practices, and have a look at a real production application that has been designed using these techniques. The event will be held on 27 januari 2009 at Inxin - Haverwerf 5 - 2800 Mechelen See you there... Read More...