The classic DDD text is Eric Evans’ “Domain-driven Design: Tackling Complexity in the Heart of Software”. A blog post is not really a format that lends itself to explicating DDD.  Instead, I’m going to try to highlight two core concepts and how these core concepts are often overlooked or misunderstood.

1. The first core concept is the ubiquitous language (UL).  The UL is the language of the domain.  It is the language spoken by the users of the software systems you create.  In defined benefit pensions, the UL includes such terms as valuation, revaluation, discount rate, technical provisions, PPF, tPR, active service, in deferment, sponsor, trustee, GMP, and so on.  In DDD we should be identifying these terms, providing definitions for them, and then using them in our domain model.
2. The domain model - the second core concept - is a model of the key relationships and processes that make up the domain.  It can be expressed using whatever format is most appropriate: equations, diagrams, prose, song, interpretive dance.  However, the one format that is not generally appropriate is the one that most developers use: code.  Code is not appropriate because developers and domain experts must be able to comprehend and talk to each other about the model.  If domain experts (e.g., pensions actuaries) don’t understand C# or Java then the model should not be expressed using such languages.  Developers often try to rescue the model-expressed-in-code idea by defining an embedded domain-specific language (DSL) or arguing that their language (Haskell, F#, etc.) is so good and easy to understand that it really is the best vehicle for expressing absolutely any and all concepts of interest to humanity.  If in doubt, ask your domain experts what they are most comfortable with, and try to maintain your equanimity when they don’t say “I’m most at home using the monoid category of endofunctors as encapsulated by the monad concept in Haskell, so let’s use Haskell”.

Stepping outside of the code and learning about the concepts that are core to the domain is, to my mind, the single most valuable action a developer can take.  Unless, of course, your domain is code.  Compiler writers have it easy…said no one, ever!