Domain Driven Design

Domain Driven Design (also known as DDD) is an approach to the design of software where domain models are used to drive the design process and allow software developers and business experts to communicate more effectively. A dictionary definition of domain is: a realm or range of personal knowledge, responsibility, etc. In the context of DDD a domain is an area of knowledge or expertise that software is being developed to work in. So if you are a business owner that wishes to automate some aspect of your business, the domain is the operation of your business. Put in a different way, the domain in DDD refers to the area of expertise that end users of the software being developed understand and work in.

A domain model is a conceptual model of the area of expertise or organizational system the software is being developed for. For a business owner, this could be a conceptual model of their business or a part of their business operations. It can take the form of a document, a series of diagrams, some scratchings on a whiteboard or a more formal definition in a modeling language such as UML. All people have domain models in their head for a whole bunch of different knowledge areas and expertise.

The power of Domain Driven Design comes from the alignment of the domain models in the heads of the various stakeholders of a software product or project. Aligning how the software developers, business owner and users of the software perceive and think of a system being automated by software allows the entire development and maintenance process to proceed more quickly and better equipped to satisfy the needs of everyone involved.

The language used when the different software product stake holders communicate subtley, but greatly, affects their interactions. The term ubiquitous language is used in DDD to describe the use of a consistent domain language between all of the stakeholders, software developers, end users, business management, business experts etc. Torq Software uses Domain Driven Design techniques in the development of the software products have created and maintain. An example of the use of DDD and ubiquitous language can be found in the Iris Debt Collection System design.

The concept of a debt collection Job was the central theme to the business operation, so this is the term we used in the software source code to label that software class. Similarly the terms Client, Agent, Agency, Client Contact and Tow Company were all in use by the debt collection industry the business deals with. These are directly used in the Iris product's source code which allows the software developers to associate software concepts with business concepts. It allows the developers to more effectively communicate with the users of the software. So rather than have a software jargon, we have a shared jargon that straddles the software development process and the debt collection domain (for this case).

An interesting variation in the DDD approach used was the naming of the Coordinator concept. The business didn't actually have an explicit name for the office staff that worked on debt collection jobs but were not actually field agents. We found that this role in the debt collection workflow was important enough to model it in software. The term Coordinator was used as the person involved coordinates the activities on large numbers of jobs. This isn't quite the text book approach of using language that is already in use in the business domain, but the additional term worked well. It is now in common use within the business at it puts a common sense label on a conceptual role they were already familiar with. We typically follow an approach such as Domain Driven Design because it provides significant value to the development process but aren't averse to tailoring the approach to different scenarios.