22 March 2023
3 min
Technical Architect, Insights & Analytics
What does an actuary do? This is probably the second most common question found in the browser search histories of actuaries (the first being, does knowing how to use the Solver Excel add-in make me a data scientist?).
As a proponent of domain-driven design at Hymans Robertson, figuring out what actuaries and investment consultants do, and what they need from their tools, is a critical part of my job. Domain-driven design (DDD) is a software design philosophy that insists on the primacy of the domain in which software operates.
For a firm like Hymans Robertson, the domain is financial services with sub-domains around defined benefit pensions, defined contribution pensions, investment consultancy, and so forth.
... I'm going to try to highlight two core concepts and how these core concepts are often overlooked or misunderstood.
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.
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.
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!
If you would like to find out more contact us.
We pride ourselves on being thought leaders and are constantly discussing the many issues facing and shaping our industry. Sign up to find our current thinking on topical issues.
Opens in new window Subscribe
