Programmer's Life: From MVC to DDD

I was using MVC model for over six years. It was – and actually still is – a great model for the work we were doing. Small intranets for various companies, containing mainly employee or client information, didn’t call for robust or overcomplicated solutions. Our clients usually needed the same things over and over again, just named differently. Therefore, we had simple bundles for each part of the process (invoicing, file management, users and authentication, orders, etc.) which were used in various project. Basically, each new project was a simple puzzle with a few additional changes or new features. The work was simpler also for new programmers. The company was stable, the work we provided was of a high quality, and the MVC model was easy to grasp.

Then I changed my job and got to Pixel Federation. I was allocated to our new game – Train Station II. As soon as I could, I installed the game and started to play it. At first, I thought that game about trains would be boring, or only for train enthusiasts like Sheldon Cooper from BBT, but it caught my attention immediately. I found the story jobs fun to read, and standard jobs interesting to fulfil. I liked the combination of getting materials, producing products in factories, fulfilling jobs, and building the city … suddenly, I could play the game for hours. Naturally, I couldn’t wait to see the code behind it. I was curious and eager to learn. I really thought that DDD would be simple. I have to admit I was wrong.

I tried to approach the whole architecture in the view of things I knew. I used to be a full stack developer who could create a whole project without any difficulties. The Controller receives a request then calls the Model (database and services) where the logic is stored, and then the result of the logic is shown to users via the View; linear and easy. So, my first impulse was to find the entrance point and with it the whole logic in the layer behind it. It took me two hours to find the entrance point. Then I got completely lost.

Therefore, I did what always helped me in the past: I turned to books. I found out that DDD stands for Domain Driver Design and is separating Infrastructure, Application, and of course Domain. This was how far books helped me at that time. The rest was trials and tribulations. I was still unable to grasp the complexity of the architecture. The first month was a disaster. I couldn’t do the simplest things, I was unable to cope with simple problems, and I was constantly lost in the code.

After the first two weeks, I finally figured out where and how to change the name of the train station. I was happy with my success. Five minutes later, new information came: we wouldn’t be naming train stations but players. The code had to be changed. I nearly wept when I heard this.

I was dismayed, but after another two weeks, it all started to come together. There were many new words and principles that I needed to follow, but they made sense. Though the system was complex, it provided many advantages: autonomy of services suddenly got a new meaning; single responsibility was real, not just so-so; reusing the code was out of question, so no duplications messed up the code; bounded contexts ensured that one change didn’t effect already created and tested code (unless we wanted to). Even though the system was complex, additional changes became simple, clear, and feasible. My whole outlook on programming changed with this new experience.

I’m no longer lost in our DDD structure. I like this system with all its advantages and complexity. There is no one way how to program in DDD. And there sure isn’t only one correct way. Though I think that DDD is great, and it sure helps with development of our game, I won’t now go claiming that it’s the only way how to write code. As with every pattern, there are advantages and disadvantages to the system. If a friend approached me with a simple website, I wouldn’t use DDD to set it up. But I can’t imagine doing something as complex as Train Station II in any other pattern. I’m sure that after the global launch in July 2019, we’ll have stable and easy to change code. I’m looking forward to it.