Not Quite the Master of my domain

Now now, for those who have watched Seinfeld, I am not talking about “that” domain. I am referring to the domain of the project; the business domain. Taken from google, “the business domain is a specific area of a business that software is designed to support. It’s a well-defined area with its own language, rules, and processes.” For those who didn’t get that (I barely got it myself), it is knowledge of the ins-and-outs of your product, from the business perspective. As a developer, I can easily explain how to show a list of users with for-loop or while-loop. However, a layer above that are the rules dictate “which users to show” or even “should I see a list users at all”. These kinds of rules and decisions make up the “business” layer.

When I first learned that I was moving into a tech lead role, I wasted no time jumping on Google to find out how to prepare for it. I typically look for books because they are more in-depth with the topics they discuss. During my search, I stumbled upon a book called Domain-Driven Design by Eric Evans. Up until this point, I had never heard of domain-driven design or DDD. So, thus began a mad dash through the book, hoping to learn the lessons well enough before starting the new job.

Uphill Climb

While I wish I had more time to study the book before I started, it did help me change my perspective and approach to learning about this new team and project. I became hyper-focused on learning the business rules—the whats and the whys. The struggle is that my project’s domain is huge. There is my front-end project, which has a lot of rules. Then, there is the large backend that has even more rules. I have made decent progress on the front-end, but recently I’ve made a push to try and understand the larger backend, and I have struggled. I learn one piece, and then several threads spring from what I just learned.

It’s daunting, but I am a determined person. I think what helps me is breaking things down into smaller chunks (which also applies to facing most problems). One strategy I incorporated was spending 15 minutes a day looking at some piece of the large backend and data. With all the managing, supporting, and issues that come up in a day, it is the most I’m willing to commit to. I do pretty well with sticking to it. Another strategy I use is taking notes whenever a subject matter expert (SME) speaks about the domain, even in daily stand-ups. These SMEs can be the business unit, developers, testers, or anyone else who is familiar. If they are talking, I’m writing/typing. I do have a long way to go, but I just need to remember to take it one day at a time.