Some time ago I worked on accounting application for hotel booking domain. When the hotel was booked, the system created an accrual – information about how much money will our customer pay to supplier (hotel itself or some broker like travel agency). After some time the customer received the invoice from supplier – then accountant entered the invoice into our system, the system matched the accrual with the invoice. At the end system created xml exports to SAP ERP.
The xml was horrible – nodes names was like HKONT and values like X or P, it had no sense for me. I tried to read the documentation from our customer, but it did not help a lot. So what that something is gl account, or even few questions later – gain/lost account? What it supposed to mean?! And the code was structured the way showing developer misunderstanding of the export – it was just a bunch of fabrics and builders dedicated for some (group of) abstract nodes. At some point – when a lot of bugs appeared and I had to clean it up – I was very frustrated. I had to ask our customer-super-accountants how the xml should looks like! Thanks to God they knew it…
After a year of my work with that codebase the company decided to extract part of export generation to dedicated service. We decided to do it properly – at first, get to know what is going on. It turned out that the export was showing the very basic accounting process – debits and credits double-entry system. If you start learning accounting – it’s first lesson in you course. But we were developers and we implemented it “programming” way.
This story taught me that it’s not enough to be just a good developer. As a programmer I have to also understand the domain of maintained application. That’s the reason I started to read about DDD. Domain-Driven Design sounds like the answer for my problem – the hint how to implement the actual business process, model / describe the service the company provides to its clients.
If we understand domain as a problem space, domain model is a solution space (one of possible solutions). One of developer’s responsibility is to learn domain. When your customer is talking about creating a user instead of registering, or setting active flag on the user record instead of activating the user account – you should have a bad filling about this.
There are many definitions of DDD – toolbox of design patterns, methodology, approach to software development or business domain complexity, even philosophy. I like to believe that DDD is about communication: between developers and business people, between developers, between the code and spoken language, but also between companies departments and even business people from different companies. It’s all about shared understanding, about building common language. Ubiquitous language allows me as a developer to understand the problem and look for solution, instead of guessing which letter or number should be in which xml node.
I’m too old to believe in The Ideal Remedy. DDD is a huge topic and the definitive definition for that just does not exist. In the same situation are domain models and ubiquitous language. You will redefine them by day to day discussions, find a better words, find missing words, find different meaning of the word in various contexts. It’s neverending story.
