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 QuicklyAfter 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 LiteFor 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 OOMartin 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 DilemmaSo 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.