Wizards of Smart

Dogs and Cats Living Together

You’ve probably read Joel’s post on The Duct Tape Programmer and several responses. I did not like Joel’s post at first, as I thought it far too general and easily taken in the context of “always do it this way.” For the record, I have no problems with the duct tape approach when trying something out, but I’ve been burned when having to work on someone else’s let-me-try-this project that then became a core, production system. That’s a formula for PAIN. That said, I think you can make a case for using a duct tape approach for some, small parts of your application.

This past week I put together a presentation on DDD for my office. I included some slides describing DDDD and CQS as Greg Young has discussed time and again. While I put together those slides and thinking about Bounded Contexts, I had a sudden realization that even within a single Bounded Context or Module, you could mix duct tape with quality when using CQS.

If you look at the diagram above, you can easily see where this is possible. If you split your module into read and write contexts, you can focus your greatest efforts for quality on the write side, where your domain lives, and leave the ever-changing read side to duct tape, RAD, etc. for displaying in the UI or reporting. The idea here is that you will often find that what you need to persist doesn’t change very much, but what you are asked to display changes nearly constantly. That’s at least my experience.

Another benefit to this approach is on the sales pipeline. Creating applications consists of these two parts: reading and writing. You may find that clients who have their own internal developers may not want to hire a consultant or contracting firm to build an entire app at their normal rates, but if you can provide them the write side and architecture guidance for the rest of the app, you may be able to sell more projects and keep your people happy working on quality code and quality projects. Of course, that’s just theory at this point.

So is this a case of “mass hysteria”? I don’t know. I like the idea, if not so much for the inclusion of duct tape as the possibility of limiting changes to the core domain models in an application architecture. I’m curious to know what others think or have done.

If you have been following the DDD and DDDD waves, you’re sure to have come across the CQS pattern. When I first heard of this, I immediately liked it but thought it was surely a pattern for very, very large systems. Most systems probably don’t need CQS, but this morning over breakfast, a discussion with my wife on child learning patterns made me rethink this.

We have a friend whose children have grown at very different rates of reading comprehension and writing skill. The interesting part is that the rates are nearly opposite from one another. The one with excellent reading comprehension does not excel at writing while the other is and excellent writer but has trouble reading. I found this somewhat strange. After all, logically, I would think that the one who reads should be able to write better. But that’s not the case. No one can do everything best. The same is true of databases.

This is such a true statement that in the Collective Intelligence session at the Houston ALT.NET Open Spaces, four distinct database tiers were promoted for proper separation of concerns to allow each tier to most effectively perform its task. Is this necessary for every application? Probably not, but as we move toward a more virtualized server world, the cost is really swinging in the favor of using multiple databases for reading and writing concerns. This may break the YAGNI principle, but I think we may often find that simplest may really be the best, simplest, smallest part that can fit the bill. (I’m sure that last statement will really ruffle feathers, but that’s where I am atm.)

I followed Microsoft P&P’s Application Architecture Guide‘s progress closely, right up until the point it was released. I still haven’t read it all the way through, and at this point, I might not. J.D. Meier posted several of the pattern diagrams today, and I was quite surprised by what I saw. I posted a comment on the Web Application with Domain Entity Application Pattern post, but I think a few others say it much better:

• Ayende Rahien
• Colin Jack (and again)
• Greg Young
• John Rusk

To their credit, I noticed the App Arch guys added a how-to for DDD, and after a brief scan, I don’t think it looks half bad.

What are some of your thoughts? Have any of you read the guidance? Should it be called guidance? Are those of us who are dissatisfied wrong, and if so, what are we missing?

I recently came upon a question in the Domain Driven Design Yahoo! Groups asking whether or not the presentation layer should interact directly with repositories or through a method on the entity (domain model). Having just finished Nilsson’s Applying Domain Driven Design Patterns and (finally) getting my head around LINQ to SQL on my current project, I decided to weigh in on the matter.

As always, it depends. You can indeed allow the presentation layer to use the repository directly, just as you can allow the presentation layer to use a factory to create your entities. Your current implementation is something I started off with when I started trying to do DDD, and follows more of the Active Record pattern, as mentioned by another responder, thought Active Record, by definition, matches the database table field for field.

You have several options:

1. Use your current approach. You’ll probably need to merge your repository and entity by using static methods and properties, though, which can make it messy, and I wouldn’t recommend it. That’s why I stopped using this approach, anyway.
2. Add a validation mechanism to your repository to validate your entities or, if your entities validate themselves, report the entities’ validation before you save.
3. If you really like the Save method on your entity and you use .NET or a dynamic language (not sure about other platforms), you can use extension methods to “add” a Save method that wraps a call to your repository. This is really option 2 with some syntactic sugar.
4. BEST PRACTICE (?): Use a Unit of Work, such as LINQ to SQL’s DataContext, Entity Framework’s ObjectContext, or NHibernate’s / SubSonic 3′s ISession to manage transactions and repsoitories, then call SubmitChanges() through the unit of work.

The Unit of Work pattern can be a little hard to understand at first, but it is quite powerful and great for managing rollbacks (which are extremely difficult if you always wrap your unit of work/repositories in the entity methods).

For reference, try these links:
http://iridescence.no/post/ASPNET-MVC-DataContext-and-The-Unit-of-Work-Pattern.aspx
http://www.west-wind.com/weblog/posts/246222.aspx

For keeping LINQ to SQL and Entity Framework persistence ignorant (PI), see:
http://iancooper.spaces.live.com/blog/cns!844BD2811F9ABE9C!397.entry
http://code.msdn.microsoft.com/EFPocoAdapter