This post is another one of my quick cheat sheets to an alt-coder buzz phrase being bandied about, in this case Domain Driven Design. After reading this you should be able to understand what the A-Listers are talking about when they post about how they emphasize DDD to their teams along with TDD, IoC, and F73-persistence (Ok, I just made that last one up).
First off lets clear up a quick point. The ‘Domain’ in Domain Driven Design refers to a domain of expertise or business such as banking, aerospace, llama farming, etc. It does not in this case refer to any sort of technical-system use of the word domain like a Microsoft network domain or any other such imaginary nonsense.
For comparison, here is a quick bullet list of typical tighty-whitey, non-DDD project:
- Some non-social-liability business analyst or project manager (PM) meets with business guys / gals to get the specs.
- Said PM learns from business people about the business, figures out how their business need might translate into an app or website or whatever.
- PM talks to technical lead of software team, describes what the desired inputs, outputs, and business rules of the future system are.
- Dev team architects and jams out code to meet those ins-and-outs requirements based upon their best coding practices for making the calculations calculate and the reports report and wraps it up in an interface mocked up by emo Apple dude or chick.
Ok, with that in mind then, here is the fundamental DDD gist:
Domain Driven Design is a OOP software design which models itself on the way a given business domain works in the real business world. The classes, objects, naming of things, code mechanisms, etc are designed as best as possible to match the way the business that the software is being written for really functions. Rather than an end product that just takes the requisite ins and produces the requisite outs via developers coding whatever formulas and utilities they can come up with to satisfy the requirements, you strive for a product that under the code hood, actually *works* the way that the real domain does.
The DDD Process:
DDD attempts to level the information playing field, mixing the actual developers with the board room domain experts so that everyone speaks about business concepts in a shared vocabulary. While these colliding worlds may be shocking on a number of fashion, hygienic, and social levels, it is crucial to the process.
These real developers work with the business domain folks to determine how the domain works, modeling out a proposed system using a more generic UML-like workflow diagram that both the developers and business folks can understand. This visual model expresses the way the domain entities (customers, factories, widgets) and business rules work in a way that is compatible with turning into real code.
When it comes to hacking up the actual code, classes and objects are named according to the vocabulary of the domain and try to interact with each other in a way that as close as possible that reflects the way the domain works. This type of scenario lends itself to certain types of OOP coding practices such as services for business rules, factory patterns for object creation, modules for delineating big like sections of a domain (say shipping vs accounting) and loose coupling. The domain layer shouldn’t care about the UI above or the DB below.
Ok, now that you know the basics of Domain Driven Design, don’t overestimate the value of referring to it exclusively as DDD with an air of sophisticated arrogance. This is very useful for intimidating the buzzword-weak who will be too emasculated to publicly ask what it means thereby reinforcing your technical bad-assitude. Forget winning friends, influencing people is where its at!
Linkification:
JP BoodHoo – DDD proponent
Not terribly clear ‘official’ DDD site
Free 100 page-ish ebook ‘Domain Driven Design Quickly‘
When breaking into the OOP / Alt-Coder world, you’ll often see a lot of virtual methods and properties thrown around and clever people talking about them rather matter of factly, for instance at Ayende @ Rahien wishing for a virtual keyword option added in the next version of Resharper. If coming from a Java background or just trying to grok its use from scattered code snippets or funkless tech posts all this virtual stuff can be a bit perplexing. Fear not.
So, here it is. The quickest, simplest unperplexification of the virtual keyword in C# that I can muster. No foo, bar, baz needed.
–The boring but clear bit —————————–
Virtual methods and properties in base classes REQUIRE derived classes to use the ‘override‘ keyword when, well, overriding said methods and properties. If these base methods and properties on the other hand are not marked as virtual, then when you write something in a derived class with the same name and signature, you are not in fact overriding the base version, but instead just ‘hiding’ it with functionality with the same name.
——————————————————————-
What’s the practical difference you say?
Funny you should ask…..
If you have a specific derived class in your hand, say the Monkey class derived from the base of Animal, and you know damn well you have a Monkey in your hand because you made a new() Monkey, the answer is the ever popular “nothing”. The Monkey’s Speak() method for instance will get run when you ask it to with the expected results (Probably OOK in my experience).
If however, you are using an AnimalFactory to create Animals willy nilly, or are passing around other unknown Animal objects in general, the difference becomes apparent.
Situation A – virtual keyword is used
If a base Animal method or property is marked virtual, and you call said method or property on some unknown Animal, C# will see which kind of animal you really have a hold of and call ITS designated overridden version.
Ex. If it so happens that the unknown Animal you have in your hand turns out to be a Monkey, and Monkey overrides Speak(), an OOK is OOKed.
vs.
Situation B – virtual keyword is not used
If however your Animal Speak() method is NOT marked as virtual (which is the default unless you put it there) and you call the method at the generic, unknown Animal level, the Animal version will run, non-descriptively grunting perhaps, and C# won’t bother to see what actual kind of Animal you have in your hand. If, unbeknownst to you, you actually had a Monkey in your hand also having a Speak() method but not explicitly ‘overriding’ the Speak() of the Animal it won’t make a difference. Your special monkey abilities go unnoticed. Terrible.
–Duncan
[****Addendum per Oren's Comment ****]
Oren wisely brings up that maybe it would be reasonable to talk about what you can actually do with virtuals* vs. the way they behave. OK, here goes.
A stab at Interception:
Once you find yourself in the ever-exciting world of events, event handers, and delegates you will inevitably have to come to grips with the fact that invoking an event can only be done from within the class that declared the event to begin with. If you are writing a general base component resplendent with its own events that you foresee being subclassed down the line, chances are you’d like those subclasses to be able to invoke those events as well. To accomplish this, you can add a protected method who’s job it is to invoke the event, so that derived classes now have a way to fire off said event which would otherwise remain unattainable and aloof, like that girl who sat across the row from you in 9th grade Calculus.
So, to recap, the event is hidden to subclasses, so we make a go-between that can be derived.
Here’s where the virtual comes in. As we’ve already seen, by making that event-invoker method virtual, you have the opportunity to override it in your derived class it and be assured that your distinct flavor of that invoker gets run, even when the calling client isn’t sure of if they are dealing with the base or your derived version. By having the standard operating procedure be that your method invoker is the way everyone is going to invoke your events, your derived class gets to intercept the events invoked on the base class which would be otherwise unattainable at that subclassed level.
Something less complex, like say a property, benefits in a similar way. Lets say the derived class’ property has more to it than just a pedestrian getter / setter for a string. Perhaps some math is performed on an integer when set, or a week added when a DateTime is set, which is different from what happens in the base class. By virtue of those properties being virtual in a the base class, the derived class gets to again intercept the processing that happens when the property is accessed or set, guaranteeing your custom logic is followed, no matter how little your client may know about what specific type of derived object it actually has a handle on.
*Admittedly some clever details of this topic may be better tackled by others so if you have 2 cents to add, please feel free to do so. Given the dearth of ‘fun’ material about this on the web, this may very well be where folks land after googling ‘C# virtual methods’, so your help counts!
