DDD or not to DDD? That may or may not be the question.

DDD

I've had/am involved with my first commercial experience of DDD, or at the very least, something heading that way. My team are developing their first DDD software component.  I didn't realise I was at least 10 years behind the leading edge ( the year  which Eric Evans seminal work DDD was published was the same year I started my career as an embedded software developer, which is as close to enterprise development as Pluto is to the Sun)   

DDD Quickly

After being in a few larger organizations and having dealt with a fair few types of design approaches (ranging from monolithic to typical n-tier), it seems  that DDD has finally achieved mainstream adoption in the industry and the shit kickers - I include myself here -  are just about ready to consume it, and murder it potentially :) 

I have read "DDD quickly" on InfoQ, which I would highly recommend to get a flavour for DDD in general, and have recently started reading  "Implementing DDD" by Vaughn Vernon (or Vince Vaughan - as I keep saying) .  I chose this over Eric Evans' book as it is more current and seems to have lots of practical examples. The book is well written and has so far (3 chapters in) kept me  engaged and interested. Pretty good going for quite a dry subject like DDD. 
 
My first impressions of the subject are that its complex,  nuanced and subjective.  When things aren't black and white and there are lots of possible ways to skin a cat,   extra attention and leaps of faith are required.  Also because of this there are lots of terms to learn and use which in turn refer to almost every other aspect of important literature in the field of enterprise 
development (P of EAA, GoF, DDD) .  I will never be able to grok it, I have too many distractions, like life.  However, I will try and learn it enough to practice it and contribute to discussion about it. 

DDD Lite

For our team's problem at hand it appears, on the surface,  we have had some of the hard work done for us and have a  bounded context with a ubiquitous language that we can play around with. Additionally  the bounded context is conveniently mapped 1-1 to a sub-domain (good practice according to Vaughn).

The lack of any analysis about what the bounded context and sub-domain are here, by our team, and also our use of just a few tactical patterns (aggregate/entity identification and the use of a repository) owe to the "DDD lite" subheading, which Vaughn says is symptomatic of a lack of strategic patterns being employed.  

That is to say our team is taking a technical approach to DDD and is not fully involved in bounded context or ubiquitous language identification at this point. (or other strategic practices). This is fortunate and unfortunate.  Fortunate that we can kick on and use tactical patterns but unfortunate in that we can't apply the strategic patterns which we will have to apply at a future point in time and thereby miss out on crucial learning in this area.

The software component was initially going to be developed  using an anaemic domain model/data model and transaction script. However, our architect saw it as a candidate for DDD, with the idea that it will prepare us for future DDD projects.
 

I don't believe there was anything particularly wrong with the familiar and fairly straight-forward approach (anaemic/transaction script), we were going to use, and going on some of Vince's guidelines (or Greg young agile-esque T-shirt size - Small Small estimation), the component wouldn't necessarily be a priority for DDD love, as it is not in a core domain or a particularly complex sub-domain, but I have to agree with my architect, it does seem that it is useful as a stepping stone as our team gear up for more DDD development.  

The bounded context is a little lacking though, there are no invariants,  and consistency is a fairly straightforward affair.   There is no usage of domain events, either, for example.  However, the structure of the component means it aligns to a ports and adapters type architecture, where we can plug in back ends and front ends in with ease  (for example we plug in a resilient/distributed messaging framework  to communicate with other bounded contexts).

Back to OO

Martin Fowler describes the anaemic model in less than favourable terms.  I have seen it used in my enterprise and elsewhere.  I now know where I have seen it correctly used, in simple RESTful CRUD components for example, and "wrongly" used if what you end up doing is  pulling behavior into a myriad of "domain?" services  -  which is arguably an easier way to get to work done on some data - and transposing/pivoting behavior out of  domain objects and splaying/fanning  it into "services", relying on DI to pull everything together. If your constructor has 15 dependencies maybe something is a bit smelly.

So with DDD what happens regarding anaemia?. We feed the domain model up by falling back on encapsulation, a fundamental tenet of OO, where state and behaviour - on that state - are packaged together, heping form what is known as a rich domain model. 

We are told it is a big problem that this kind of stuff has been abandoned for the skinny latte way of design, but I do wonder how bad it actually is.   


The Dilemma

So now we are developing using DDD (or "DDD lite") and this goes back to the question in this post's title.  Should we or shouldn't we? It seems that this decision shouldn't just be based on technical considerations or that the decision should just be outright rejection because of hearsay about complexity, over engineering or the absence of a highly-skilled hero team.  Vaughn states that DDD is a complex process but out of it can drop a clear and simple manifestation of a solution to a set of  business problems. 

There are a series of questions that should be asked before embarking down the DDD route which people like Greg Young and Vaughn Vernon both advocate asking.  One of those shared by them goes something like: "By embarking on DDD for your software, is this adding value to the competitive advantage of the business the software is being developed for?".  

In this instance we are adding value to the competitive advantage of the business - even if it is marginal.  We are also providing ourselves with a firmer footing for DDD work in the future, which will see further value added.  So maybe that's OK even if we are just doing "DDD Lite" for now.  

If adopting only some of the tactical patterns give us marginal improvements this is  still worthwhile and not hurting the business, and if an opportunity like this on a project you are working on presents itself - to get a leg up  with DDD without going the whole hog - then it should be considered.










Comments

  1. Useful article. I wonder how things panned out two year on?

    ReplyDelete
  2. Useful article. I wonder how things panned out two year on?

    ReplyDelete
  3. A bit of a late reply. Well nearly 3 years on and there are bits of DDD approach slathered around our codebase and at a higher level evidence of decomposing problems into solutions. There are elements of good and bad tactical design. Although definitely related and perhaps not executed so well is Microservices, both the definition, execution and the big big problem (at least for us) of actually deploying them. Perhaps alot of it is fluffy bullshit, given that regardless of whatever twsited creation is deployed, money is still being made, so who really cares?

    ReplyDelete

Post a Comment

Popular posts from this blog

Book Review: Test Driven Development By Example (Kent Beck)

SSDT March 2014 Static Code Analysis Extensibility

Testing, Testing, 1.2.3.4.5.6..ad infinitum