DDD Step By Step
A Practical Guide to Domain Driven Design

January 2010 - DDD on the Web

Sort by: Most Recent | Most Viewed | Most Commented

  • Evolutionary Architecture by Jimmy Bogard

    A popular cause the Agile folks like to rally against is the idea of a Big Design Up Front (BDUF).  But much like Waterfall, the people doing BDUF will hardly admit that it’s BDUF that they’re doing.  Instead, you’re much more likely to get a bevy of really convincing cautionary tales of what might happen if you don’t do a certain design.  With enough experience under their belt, the architect slips into a “Just-In-Case” design mode, where the myriad of pain points encountered in the past leave a design that’s hardened against every possible difficulty that might come up. Instead of a well architected design, you’ll have one that’s over-abstracted, over-engineered, over-complicated and very difficult for the next developer to come on board and understand.  But there’s an alternative approach.  The better choice instead of BDUF is a collection of design and architecture techniques that both delay decisions until they’re absolutely necessary, and refactoring practices to evolve our design when assumptions are proved incorrect. Technique #1: YAGNI YAGNI stands for “ You Aren’t Gonna Need It ”.  It’s a generally philosophy of waiting until code actually needs to be written before writing it.  Instead...

  • Business Primitives (1/2) by drusellers

    Understanding the business has been stated time and again as being an important part of the development process. In order for me to better support the business one of the 'little' things that I am finding greater and greater love for is the 'business primitive', a very small object, often containing only a single field, that completely encapsulates one small, well defined idea of the business. This is most often a specific type of data, like 'Money'. This does a couple of things for me right off the bat. One, my methods can now ask for these 'business primitives' rather than a language primitive which means there is more meaning in my methods so that they need less documentation and that I am less likely to pass the wrong string into the wrong position on a multi-parameter method. Two, I tend to stop talking in 'developer-speak' and start talking in the language of the business. "Ahh, so an Instrument is identified by a CUSIP!" This is also a very easy way to start experiencing the benefits of DDD's 'Ubiquitous Language', as you build up a collection of business primitives your ability to discuss the business problem with the business people in the terms of the business...

  • Context and Best Practices by Jimmy Bogard

    Last night, I had a Skype/SharedView session with a buddy in Arkansas trying to apply DDD and “best practices” to an application he was building.  He wanted to use all the ALT.NET tools he’s heard so much about, such as NHibernate, StructureMap and so on.  The problem came when he went to go look at the sample applications for “Floogle Architecture”, and was basically stopped dead in his tracks.  His question to me was, “do I really have to do all this?  It seems like a little overkill”.  He had looked at several reference applications for every different Floogle Architecture out there, and all confused more than enlightened. Back when I was getting started trying to apply design principles to my work, I also yearned for that golden reference application that would just tell me what I needed to do, or at least show me what I shouldn’t do.  I remember looking at JP Boodhoo’s application he built after a Nuthin But Dot Net course, and I had the same thoughts.  “Do I really have to do all this?  It seems like a little overkill.”  What my buddy and I were missing was context . Earlier that day, I had a Q&A session with another buddy in town that’s been developing Rails apps to production...

  • A Train of Thought: January 2010 Edition by Jeremy D. Miller

    One of my New Year’s resolutions was to resuscitate my blog. It’s very obvious that the “conversation” has moved onto Twitter in the last couple years and my blogging output among many others has fallen off dramatically. Instead of pushing little throwaway blurbs to Twitter and forgetting all about it, I thought I’d try the old way. So here’s a bunch of throwaway blog comments… On Entity Framework 4 I think EF4 looks worlds better than EF1 did. There, are you happy Keith ? I still don’t like EF4 in comparison to you know what, but the remaining issues are much smaller than with the very seriously flawed v1 release. At this point, from the outside looking in, it looks like something that I could use if I ever got into a shop that couldn’t use OSS tooling or if it’s a project that doesn’t really need a rich domain model. EF4 is still missing too many important features that my team depends on with NHibernate, but that gap has closed dramatically. Specifically, if EF vNext supports “rich” POCO model (EF4’s “POCO” support only does anemic domain models and that is important to my team), closes the gap with Fluent NHibernate’s conventions...

  • Much Ado About Monads – Creating Extended Builders Part II by Matthew.Podwysocki

    In this series, we’ve looked custom computation expressions, what they are, how they are applicable to development and how we might implement them in F#.  In the previous post , we went over some of the basic methods you can include on your custom computation expression to allow for a more rich programmatic model than the linear style provided via both Bind and Return. Explaining More Methods Let’s continue where we left off last time.  Previously, we covered Bind, Return, ReturnFrom, Zero and Combine.  This time, we’ll pick it up with exception handling and resource management. Implementing the TryCatch Method The first method we’ll cover today is called TryCatch, which is self describing in what it does.  This allows us, when implemented, to use try/catch blocks inside our custom computation expression.  In order to enable this functionality, the method should have the following signature which takes a computation and a function exception handler which takes a function and returns a Monad<’T> result. type Builder = member TryWith : comp : Monad < ' T> * handler : (exn -> Monad < ' T>) -> Monad < ' T> Now, let’s write a test to show an example of how this would work...

  • Writing plug-ins for ReSharper: Part 1 of Undefined by Hadi Hariri

    ReSharper does a lot of things, but as they say, you can’t please all the people all of the time. However, one the great things about ReSharper is that it is quite extensible and there are already quite a number plug-ins available. Some of the better known ones are: - StyleCop for ReSharper by Howard Van Rooijen - TDD Productivity Plugin by Eric Hexter - ReSharper Test Runner for MSpec by Alexander Groß and of course there is also the repository of plug-ins available from the JetBrains site , where many of these are located. Now I’m no expert on writing plug-ins for ReSharper, and the authors of the previous ones leave the bar quite high, but seeing that I actually now have the time to play with them, I’ve decided to do so by sharing my experiences with you in a series of blog posts. The ReSharper API is pretty extensive and can be overwhelming as I’ve been discovering, so I want to try and take it slowly. This might mean that at times, the code is not always complete and might be missing a few checks for example, but will come in due course. Everything that I’ll cover applies to version 5.0 which is currently in Beta . There have been some changes from previous versions so if you’re working...

  • ASP.NET Performance - Part 3 - Cache Busting by karl

    In part 2 of the series we looked at ways to tweak our headers to maximize performance. One of those tweaks was the addition of far-reaching expiry headers for static files (images, css, js). What happens though when you need to change those files? We can make a change to the file on the server, but clients that got the previous version won't request the new file since the headers that came with the initial one told them not to. You may be thinking that a simple solution would be to set a shorter expiration time. But that only masks the problem while negating the benefits we're after. What we're after is a solution that'll let us maximize caching yet allow us to update content on demand. HTTP caching works off the requested URL. The browser makes a request for a URL, and gets a response, which contains headers as well as the body. Any subsequent request to the same URL should follow any caching headers that were returned in the original request. To make matters better (or worse depending on your point of view), any proxy between you and the client can also follow this same logic. Thus, a user that visits your site might get original content, but subsequent visits by him or anyone else behind the same proxy requesting...

  • Much Ado About Monads – Reader Edition by Matthew.Podwysocki

    In the previous post , we talked a bit about the State Monad , what it is and how you could use it today in your F# application.  But, with any new piece of information such as this, it should be taken in context, and there are other patterns as well when dealing with a multi-paradigm language such as F#.  We also talked about how the State Monad might not have been the best choice for modeling our web scripting DSL as our browser state is encapsulated in the Browser class, and once it is set, it doesn’t change.  With that, we could turn our eyes to using the Reader Monad as we read from our environment. Reading From Our Environment If you recall from the previous post, we had a simple example of keeping track of browser state our ultimate goal was to have the state managed for us underneath the covers.  When dealing with the State Monad, each bind call would not only return us our calculated value, but also our new state as well.  In this case, this was wasteful due to the fact that once the state was set, it never changed, as the state was fully encapsulated inside the Browser object.  So, our ultimate goal would be instead to have our environment set once and then read from it implicitly.  We still...

  • How Dovetail uses StructureMap with NHibernate by Jeremy D. Miller

    A quick note here, this article shows features of StructureMap that are only available in the very latest 2.5.4 release available on sourceforge . I’ve uploaded the finished binaries, but haven’t made a formal announcement because I’m a couple weeks away from having the docs updated (and yes, StructureMap *is* actually well documented , thank you). My friend Weston Binford published his take on StructureMap / NHibernate bootstrapping and some on managing transactional boundaries with NHibernate in a web application. He’s been constantly nagging me to write *this* post because we do things very differently with some of the newer features in StructureMap that I haven’t documented yet (and frankly, you should thank me for dogfooding this stuff and playing whack-a-mole with memory leak bugs before inflicting it upon the world). This is *our* approach and not a canonical example of how to do everything. It’s working for us at the moment is the best that I can really say. The performance is good enough for us, but I won’t claim that it’s been tuned yet. In writing this it has definitely occurred to me that, yes, this does seem pretty complicated. There are a lot of moving parts, but at least...

  • Language Envy - C# needs Ranges by sergiopereira

    As soon as I started learning Ruby, a few years ago, I got immediately hooked on its Range class. I could not believe I had been programming in .NET without them for so long. I like to think of range objects as the specification for a for loop, packaged in an object that can be passed around. That's not the whole story, though. Ranges also represent sequences or intervals, which can be queried for intersection or containment. See the following Ruby sample code. #declare a Range object summer_months = 6..9 #enumerate it summer_months.each {|m| puts "#{Date.new(2000, m, 1).strftime('%B')} is a Summer month." } #other handy features summer_months.include? 7 # ==> true summer_months.to_a # ==> [6, 7, 8, 9] (converted to array) I needed that in C# That was back when the CLR 2.0 was just about to be released and I ended up writing my own Range class. I have used this class in a handful of projects since then and I'm still surprised that we don't have it in the standard .NET class library. The closest thing I'm aware of is the method System.Linq.Enumerable.Range(int, int) , which is rather limited (it only enumerates integers one by one). Here's the code that I came up with, which has served me...

  • cqrs for dummies – 0 of N - Overview by John Nuechterlein

    disclaimer: if you’ve ever read a ‘for dummies’ book, you know that they are designed to give a pretty decent overview of a topic from experts. Given that, this series is probably mis-named. It should be something more like “cqrs from an idiot” or something, but that’s bad marketing. Anyway, I’ll be pointing out the people who really know their stuff, with links and whatnot, but I hope to be able to give an explanation of CQRS at a high level that will be of use. update: adding missing overview paragraph at the end, and uploaded larger pictures. Goals for the series Anyone who has looked at my DDD-Lite series might wonder about the relationship between CQRS and DDD. Glad you wondered. Put crudely, DDD fits inside of CQRS. That is, the latter is an architectural style that uses a Domain Model, but goes beyond it. You can do DDD without doing CQRS. It is technically possible to do CQRS without DDD, but they fit together well. What I want to try to do is to layout what I take to be the basic tenets of CQRS in a way that might be easier to understand in some circumstances. A full-blown implementation of CQRS involves a lot of concepts that have a lot of implications, some of which, in my opinion, are not logically required. The concepts...