Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Programmer's Life: From MVC to DDD

by Jane Sefc on 06/04/19 10:24:00 am

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


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.

Related Jobs

HB Studios
HB Studios — Lunenburg/Halifax, Nova Scotia, Canada

Experienced Software Engineer
University of Exeter
University of Exeter — Exeter, England, United Kingdom

Serious Games Developer
innogames — Hamburg, Germany

PHP Developer - Tribal Wars
innogames — Hamburg, Germany

Java Software Developer - New Mobile Game

Loading Comments

loader image