Domain-Driven Design (DDD) is an approach for dealing with highly complex domains using a well thought-out domain model. This article explains DDD concepts using a real example. For a detailed description of the approach please refer to the Domain-Driven Design book by Eric Evans.

The example used in this article is Bullsfirst, a sample trading system built to demonstrate the use of best practices and patterns to solve real world problems. The diagram below shows the Bullsfirst vision. It consists of several system components built using a variety of technologies as a means of learning and evaluating different design approaches and platforms.

The Developer’s Guide to Microsoft Prism provides an excellent source of information for Prism and MEF. It includes extensive documentation, QuickStarts and reference implementations that are very helpful. However, when I was starting out with Prism 4.0, I found that even the simplest MEF application included in this guide was a bit complex for me to use as a template for my own first Prism application. Now that I’ve crossed this hurdle, I’ve written a simple tutorial for people in my situation.

We’ll build a simple “Hello World” application (here’s the live demo and the source). You type in your name, and it responds with “Hello <your name>”. Of course, we’ll use Prism and MEF to make this a modular application. The finished app looks like this:

Context: Business and Technology Silos

In my experience, there's often a lack of clarity and communication between business and technology – not because they don’t like to work with each other but more because they don’t understand each other’s needs. As a result, projects generally take longer and are over budget.

Here's a very common scenario: a firm has a critical business need for which they want IT to develop an application. Unfortunately business and IT are working in their own silos. Business is writing reams of vague specifications and throwing them over the wall to technology. Technology, of course, interprets the specifications in their own way and starts to build the application. In all sincerity, the two groups meet regularly to discuss the requirements. Nevertheless, the complexity of the business problem and lack of a good process prevents these meetings to be very productive.

Months later, technology has implemented a few features. They ask the business to test them. Now that they have a real interface to play with, business starts entering all kinds of scenarios and finds that the system fails on several key ones. Technology folks begin to realize that their understanding of the business domain is very shallow and they'll have to rework the domain model in a major way!

Has this ever happened to you? Can it be prevented? I would say yes – there are several techniques we can use to make the system development process more productive, efficient and fun!

Bullsfirst is a sample trading system built to fulfill Archfirst’s goal of demonstrating how current and emerging technologies can be used to solve real world problems. It is a system of medium complexity whose domain is reasonably easy to understand. This post gives a high-level overview of Bullsfirst.

The Vision

Bullsfirst will consist of multiple order management systems and a central trading exchange – all implemented using current and emerging technologies, working seamlessly with one another.