Reading Note on DDD(Domain Driven Design) - Overview

Domain Driven Design was published in 2003, it is amazing to see a software book still in fashion after a decade – most software books are like junk food, you eat it quickly to fulfil your stomach and forge it. DDD is different, it is even more alive these days: whenever people talk about Microservice, they quote about DDD. My interest in DDD was piqued when I was researching Micorservice. And like many reviews in Amazon, I found the book to be very hard to read, after I waded through half of the book, I had to drop it down; a few months later, I picked up the book again, and this time, it was much easier to get through – I found this to be a good reading habit: whenever something is too difficult to read, I just drop it, wait some time, and pick it up again. It is as if during the cooling-off period, my unconscious mind is still doing digestion without the notice of my conscious mind.

Now that I finally understood many things about the book, I want to write them down for future references. This blog is the first in a series.  

The heart of the book is:

The complexity of software lies in how you model the business, not on mechanical implementations. The weapon to fight against software decay is to extract and distill models and to make models supple, so they can cope with changes.

In his typical roundabout way, the author goes on and on trying to make this idea across, which led many readers to complain about the repetition. But if you can read past this, the author offered many ideas about how to make it happen.

On technical side:

• Use  UBIQUITOUS LANGUAGE to describe business logic, and to unify analysis and implementation models.

What does this mean?

a)      Business models are extracted from talking to business experts, when in discussion, try to abstract concepts that are understandable to business experts, so that developers and business experts can be on the same page.

For example, compare the following two statements:

Statement 1: Whenever a user changes the customer clearance point, the system will fetch the corresponding row from table CARGO_BOOKINGS, pass it to ROUNTING SERIVICE which will re-calculate a best route, and save it back to CARGO_BOOKINGS.

This describes a mechanical process which is lost to most business experts; and it fails to abstract business rules into models, if implementation is done in the same mechanical way,   the implementation will be hard to change: for example, if a user changes the destination, various places of the implementation would have to be located and changed (locating the places to change can be quite hard, and making sure changes do not impact other places can be equally hard).

Statement 2: Whenever a user changes the customer clearance point, we will change the ROUTING SPECIFICATION, and ask ROUNTING SERVICE to recalculate a route based on the new specification.

This statement abstracts an important concept: ROUTING SPECIFICATION. With this model charted on the whiteboard, business models can point to it and say “actually, origin, destination, price are also parts of ROUTING SPECIFICATION.” If in the future, more factors are added into ROUTING SPECIFICATION, we know immediately what to change.

        It is possible that developers might stumble onto the concept of ROUTING SPECIFICATION after they changed the implementation several times – every time a user changes origin, destination, customer clearance point, they had to change the  implementation. After several times, they refactored using STRATEGY pattern and resulted in a similar implementation. While the result is the same, it is certainly much better that the concept of ROUTING SPECIFICATION is distilled in the analysis time with the input from business experts.  

b) Use the same model in business analysis and implementation.

In the previous example, ROUTING SPECIFICATION and ROUTING SERVICE can be used directly in the implementation. By unifying the two models, business logic is not lost or distorted.

(Now you can see why the book is hard to read, the terms the author has chosen are not intuitive, and even awkward. If the author had chosen better names, such as SCRUM, AGILE, SAFe, maybe the ideas he advocated would be on everyone’s lips now J)

• Various techniques are offered to address business modeling, VALUE OBJECT, ENTITY, AGGREGATE, BOUNDED CONTEXT ect. BOUNDED CONTEXT is most interesting, as many advocate a BOUNDED CONTEXT as a Microservice.

On project management side:

 

• Skilled developers are scarce, they tend to be attracted to technical infrastructure, such as performance tuning, framework building etc. These technical skills are transferable, and provide better resume materials. The core of a business application, the thing that distinguish this application from that application – the business models, is usually left to less skills developers.

    Software managers need to drive best technicians to solve the most complex issue of application: model design.

•   Models need to evolve. Continuous integration is not just about continuous code integration, but also about model integration. This requires that participants consciously exercise UBIQUITOUS LANGUAGE to hammer out a shared view of the business and the application. 

  

• Refactor is not just about making the code clean. A more impactful refactor comes about when there is a breakthrough in the models, when some logic can be neatly packed into a concept, and when this happens, refactoring might have to change a lot of code and take up a lot of time, but it will make the software more flexible. (there are some good examples in the book)

Without continuous integration and refactoring of models, models decay just as code. Some developers do not understand the original intent of the models, and make changes that impact their original usage; or they are afraid to make changes, so they duplicate code – code decay is a result of model decay.

Software managers shouldn’t expect a steady burn down chart, an impactful refactor might setback the progress quite a lot (there is an example in the book), but if such a refactor brings out clearer and more supple business models, the effort is worthy it.