The first time I heard about DDD (stands for Domain Driven Design, not Deadline Driven Design ^_^), that was when i was still working as a Senior Java Developer for Hewlett-Packard on its Development Center at Cyberjaya, Malaysia. I wasn’t quite interest with the topic since it was difficult to get a good resource during that time. My technical lead (Hi Fadzlan, howdy man ? ^_^) just told me to find the Eric Evan’s book (“the blue book”), and gotcha..i got the book and added it to my PDF collection 🙂. However, i was merely read the first chapter and never got any chance to finish the book due to my workload.
Few months ago, i started to join Bhinneka.com (i.e. one of the pioneer for e-commerce in Indonesia), and guess what.., as the new head of architecture and backend in Bhinneka, i decided to implement Domain Driven Design in our reengineering process (yes, you hear me right, we’re going to build Bhinneka’s software from scratch, not merely refactoring).
During this time, DDD is quite new (especially in Indonesia), thus only few companies have successfully implemented this DDD. And somehow IMO, i found that many DDD resources were too difficult to be grasped by most of the readers (i.e. they are too abstract and lack of good examples). Therefore, i’m planning to pick up this awesome topic and write it in a series, equipped with an application sample to be followed step by step.
This is the first part of another series those are still in my head as follow:
- DDD Part I, Introduction –> You are here
- DDD Part II, DDD Application (coming soon)
- DDD Part III, DDD and Microservices (coming soon)
In this first part of Introduction, i would like to start with some basic concepts as written below:
- What is DDD all about ?
- How do we get started ?
- What should we avoid in DDD ?
Let’s get started 🙂.
1. What is DDD all about ?
To start this section, I’d rather took the definition from one of DDD’s community (i.e. dddcommunity.org), that describes DDD (Domain Driven Design) as an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.
As the definition implies, DDD is suitable for you if you’re building a software that has complexity on its business process (business domain). So, not every software is suitable for DDD (e.g.: CRUD application doesn’t suitable for it since it’s not quite complex).
Eventually, team work is very important within DDD since you need to keep in touch with the users/clients (a.k.a Domain Experts). Moreover, you build the software for them, not for you (you got the point right). Just like someone said: “the software can fail either in two ways, you build the things wrong or you build the wrong things”. In that case, you have to ensure that you understand correctly the business that you’re going to build. This is DDD all about.
We’ll continue later with the next point soon as I can. It’s already late now. Just stay tuned..