Buzzword Buster — DDD

Definition:

Domain Driv­en Design (DDD) is an approach to soft­ware design which puts the focus on the prob­lem domain and pro­vides a struc­ture for mak­ing design deci­sions to accel­er­ates soft­ware devel­op­ment for com­pli­cat­ed domains. The key com­po­nents in DDD include:

Domain: the sub­ject area to which your pro­gram is applied

Mod­el: abstrac­tions that describe aspects of a domain and can be used to solve prob­lems relat­ed to that domain

Domain Experts: peo­ple with the most com­plete knowl­edge about the world your sys­tem will live in

Ubiq­ui­tous lan­guage: a lan­guage around the domain mod­el used by all team mem­bers, the lan­guage is ubiq­ui­tous because it is present every­where

Purpose:

Tra­di­tion­al­ly .Net appli­ca­tions are devel­oped using a data-cen­tric approach where you build your sys­tem around your under­stand­ing of the data – cre­at­ing all the tables and the rela­tion­ships in the Data­base and then mir­ror them in your .Net code. This approach is pop­u­lar because of the ease and speed with which you can cre­ate a ful­ly func­tion­al sys­tem from the ground up.

DDD on the oth­er hand, focus­es on the prob­lem domain as a whole which cov­ers not only the data but also the behav­iour. DDD encour­ages greater involve­ment from domain experts, the idea is to build your sys­tem in a man­ner that’s reflec­tive of the actu­al prob­lem domain you are try­ing to solve and let the domain dri­ve your design deci­sions.

One of the great­est chal­lenges in devel­op­ing a new sys­tem is to learn and under­stand the new busi­ness, which is why a sin­gle, shared lan­guage (the ubiq­ui­tous lan­guage) between the users and the devel­op­ers can go a long way to reduce mis­in­ter­pre­ta­tions and cre­ate a more con­cise and effec­tive com­mu­ni­ca­tion amongst all inter­est­ed par­ties.

Parting thoughts…

It is impor­tant to remem­ber that whilst DDD is bet­ter than the data-cen­tric approach in some cas­es, the reverse is also true.

Also, DDD car­ries with it the over­head on the devel­op­ers’ part to become pro­fi­cient (or some­times experts!) in the prob­lem domain and being able to com­mu­ni­cate with the users in an com­mon lan­guage.

Mas­ter­ing both pro­gram­ming skills and busi­ness knowl­edge in the core prob­lem domain is dif­fi­cult and takes sig­nif­i­cant­ly longer than the course of devel­op­ing an appli­ca­tion — sea­soned devel­op­ers in the Finan­cial sec­tor would no doubt agree with this! This is one of the rea­sons why knowl­edge in a par­tic­u­lar area (equi­ties, deriv­a­tives, etc.) is such a valu­able asset and devel­op­ers who also qual­i­fy as domain experts in a busi­ness area are so high­ly sought after and com­pen­sat­ed.

On the hand, it is also why so many find it hard to break into Finance despite boast­ing impres­sive devel­op­ment skills, and why many oth­ers become type­cast with a spe­cif­ic industry/area and find oppor­tu­ni­ties out­side their famil­iar ter­ri­to­ries hard to come by.

Dur­ing my time with Cred­it Suisse I have come across many devel­op­ers who have spent their entire pro­fes­sion­al career in the same busi­ness area, becom­ing domain experts in their own right. Though per­son­al­ly it’s not what I’m look­ing to get out of my career I can def­i­nite­ly see the mer­its of doing so and appre­ci­ate the enthu­si­asm they have for their prob­lem domains.

Further reading:

Domain Dri­ven Design by Eric Evans