Skill game development presents a unique set of challenges—the games are generally a mix of stateful systems and stateless systems. There are also aspects of the system that do not fit into either of the two major modern software architecture paradigms: service-oriented architectures (SOA) and command query responsibility segregation (CQRS). Neither of these architectures supports a connection-oriented stateful system, which is one of the major requirements for multiplayer skill games. Every player has to be aware of the state of the game they are participating in. The game state cannot be served from different servers as an out-of-sync server will lead to an unrecoverable error state for the game. For example, a player plays their turn but it does not get synced to all the systems that different participants of the game are connected to. The other players connected to different instances will see a wrong game state and they will either not be able to proceed or will play incorrectly. We could use active-passive mirroring to make the system resilient, but we cannot go for active-active load balancing, which we generally see in e-commerce or social networking applications. Since most skill games are played for real money and the game state is random, it will be a terrible experience if the game state gets reverted. For example, if in a game of rummy, the game state gets reverted by two turns after you have made a move on your turn, your opponents will find out what card you picked from the closed deck, giving them an unfair advantage in the game. Such complications lead to unique system requirements, which makes this field more complicated than a normal e-commerce website. The What and Why of DDD (Domain-driven Design) Domain-driven design is a software design philosophy that focuses on creating a model of the domain for which software is being developed. It is not an approach adopted to model the real world, but it aims at creating an artificial model for developing software to solve the problem. The approach was introduced by Eric Evans in his book Domain-Driven Design published in 2004. The model not only helps us build software but also lays down the process to develop the system and organize the teams (by the use of bounded context). It also stresses a ubiquitous language, which helps different teams and stakeholders to use a common terminology/grammar while discussing solutions so that there is no confusion in communication. Otherwise, for example, the Accounts team might be calling an account statement a ledger while the Development team might be calling it a table, which could cause a lot of confusion in communication. The question arises: Is DDD still valid in the microservices world? Absolutely. In fact, it has become even more relevant now. Here are some of the reasons: • Bounded context helps us define the needed microservices and structure the teams accordingly. • A ubiquitous language allows teams to communicate using the same terminology/grammar and avoid confusion. • An anti-corruption layer, especially important migrations from monolithic systems, helps us break micro-services into small chunks. • Context maps allow us to understand the interaction between domains and in a way between microservices. • Domain events allow us to implement the CQRS model and data pipelines, which have become very important aspects for analytics. Important DDD concepts DDD or domain-driven design is an architectural process that focuses on understanding the business domain. It aims to map the real life domain into software systems. Some of the important concepts of DDD are as follows: Bounded Context This is arguably the most important aspect of DDD. It is driven by the fact that we have to break the domain into sub-domains and then create a virtual boundary around each of these sub-domains. The overall system is defined as a collection of these sub-domains and the interaction between them. The important point here is to prevent leakage of the concepts of a sub-domain into others. Context Maps This is the concept that shows the bounded contexts and how they relate to each other. It shows which bounded context is the upstream and which is the downstream. This helps us organize the teams’ plan for development. Also, this helps in setting up proper communication channels between the teams. The context maps should start with the current system and then evolve into the desired architecture. One point to note is that context maps are the enterprise architecture or system topology. These are just interactions from a domain point of view. Actual services and components come later. Big Ball of Mud Since there are rare occasions where one builds a product from scratch, there is an existing system that is being refactored. Many of these systems are built as monolithic systems with no boundaries between the bounded contexts. The systems are refactored piece by piece and the part that is not being pulled out is considered a single bounded context and a boundary is drawn around it. This prevents the existing system mess from creeping into the newer services being developed. The name given to such a bounded context is “big ball of mud. Anti-corruption Layer This is a very important concept, especially when migrating from an existing system that was not implemented using the same domain concepts as the new system, and the ubiquitous language was not used. In this layer, we abstract away all these violations from the Bounded Context. This layer can be made part of the repository in most instances. Ubiquitous Language One of the most important concepts within DDD, is the language with common terminology/grammar used to describe the various aspects of the system like bounded contexts, entities, value objects, domain events, etc. This helps in keeping everyone in sync with the concepts and prevents confusion caused by different names used for the same concepts. How is DDD relevant for a skill game? Most of the time, initial versions of games are developed following these steps: Core game logic is developed. Ideas for monetizing are discovered. These ideas are implemented on top of the game layer. As the game evolves, new ideas are discovered and implemented. As you’ll notice, this is an iterative process, and not all domains are known in the initial versions of the product. This leads to a software ecosystem described as a “big ball of mud” and with no ubiquitous language. This leads to the same concepts being implemented in different ways in the system. For example, payments might be handled in different ways for withdrawals and deposits. There are no defined domain events, so most of the time the data needs to be aggregated within the transactional systems, causing the analytical and transactional system boundaries to be blurred. If we adopt the DDD approach, we can create a bounded context, which makes the boundaries of each domain extremely clear. Setting such clear-cut boundaries is very important in skill game development because the context has unique technological requirements. For example, gameplay requires an always-connected system that might need to be implemented using websockets or rpc streaming, etc., while a withdrawal or deposit system can be implemented as a restful service. Similarly, the performance requirements are also different as delays in gameplay might not be acceptable but can be tolerated for other features as a trade-off for consistency. The required availability is also different for each bounded context as gameplay availability should be close to 100%, while it can be a bit lower for other features. Mixing these up can cause significant cost implications as getting 100% availability for the entire system might incur huge costs, which could have been avoided. Conclusion Domain-driven design has such a wide scope that covering the complete process in a single article is not possible. Here we just tried to illustrate why this is an excellent approach to adopt when we are developing skill games. The approach can be adopted for any system but has significant benefits when applied to the domain of skill game development. Here are a couple of books that you can read to gain insights into in this process: ● Domain-Driven Design by Eric Evans, Addison-Wesley ● Implementing Domain-Driven Design by Vaughn Vernon, Addison-Wesley Skill game development presents a unique set of challenges—the games are generally a mix of stateful systems and stateless systems. There are also aspects of the system that do not fit into either of the two major modern software architecture paradigms: service-oriented architectures (SOA) and command query responsibility segregation (CQRS). software architecture Neither of these architectures supports a connection-oriented stateful system, which is one of the major requirements for multiplayer skill games. Every player has to be aware of the state of the game they are participating in. The game state cannot be served from different servers as an out-of-sync server will lead to an unrecoverable error state for the game. For example, a player plays their turn but it does not get synced to all the systems that different participants of the game are connected to. The other players connected to different instances will see a wrong game state and they will either not be able to proceed or will play incorrectly. We could use active-passive mirroring to make the system resilient, but we cannot go for active-active load balancing, which we generally see in e-commerce or social networking applications. Since most skill games are played for real money and the game state is random, it will be a terrible experience if the game state gets reverted. For example, if in a game of rummy, the game state gets reverted by two turns after you have made a move on your turn, your opponents will find out what card you picked from the closed deck, giving them an unfair advantage in the game. Such complications lead to unique system requirements, which makes this field more complicated than a normal e-commerce website. The What and Why of DDD (Domain-driven Design) The What and Why of DDD (Domain-driven Design) Domain-driven design is a software design philosophy that focuses on creating a model of the domain for which software is being developed. It is not an approach adopted to model the real world, but it aims at creating an artificial model for developing software to solve the problem. The approach was introduced by Eric Evans in his book Domain-Driven Design published in 2004. Domain-Driven Design The model not only helps us build software but also lays down the process to develop the system and organize the teams (by the use of bounded context). It also stresses a ubiquitous language, which helps different teams and stakeholders to use a common terminology/grammar while discussing solutions so that there is no confusion in communication. Otherwise, for example, the Accounts team might be calling an account statement a ledger while the Development team might be calling it a table, which could cause a lot of confusion in communication. The question arises: Is DDD still valid in the microservices world? Absolutely. In fact, it has become even more relevant now. Here are some of the reasons: • Bounded context helps us define the needed microservices and structure the teams accordingly. Bounded context • A ubiquitous language allows teams to communicate using the same terminology/grammar and avoid confusion. ubiquitous language • An anti-corruption layer, especially important migrations from monolithic systems, helps us break micro-services into small chunks. anti-corruption layer, • Context maps allow us to understand the interaction between domains and in a way between microservices. Context maps • Domain events allow us to implement the CQRS model and data pipelines, which have become very important aspects for analytics. Domain events Important DDD concepts Important DDD concepts DDD or domain-driven design is an architectural process that focuses on understanding the business domain. It aims to map the real life domain into software systems. Some of the important concepts of DDD are as follows: Bounded Context This is arguably the most important aspect of DDD. It is driven by the fact that we have to break the domain into sub-domains and then create a virtual boundary around each of these sub-domains. The overall system is defined as a collection of these sub-domains and the interaction between them. The important point here is to prevent leakage of the concepts of a sub-domain into others. Context Maps This is the concept that shows the bounded contexts and how they relate to each other. It shows which bounded context is the upstream and which is the downstream. This helps us organize the teams’ plan for development. Also, this helps in setting up proper communication channels between the teams. The context maps should start with the current system and then evolve into the desired architecture. One point to note is that context maps are the enterprise architecture or system topology. These are just interactions from a domain point of view. Actual services and components come later. Big Ball of Mud Since there are rare occasions where one builds a product from scratch, there is an existing system that is being refactored. Many of these systems are built as monolithic systems with no boundaries between the bounded contexts. The systems are refactored piece by piece and the part that is not being pulled out is considered a single bounded context and a boundary is drawn around it. This prevents the existing system mess from creeping into the newer services being developed. The name given to such a bounded context is “big ball of mud. Anti-corruption Layer This is a very important concept, especially when migrating from an existing system that was not implemented using the same domain concepts as the new system, and the ubiquitous language was not used. In this layer, we abstract away all these violations from the Bounded Context. This layer can be made part of the repository in most instances. Ubiquitous Language One of the most important concepts within DDD, is the language with common terminology/grammar used to describe the various aspects of the system like bounded contexts, entities, value objects, domain events, etc. This helps in keeping everyone in sync with the concepts and prevents confusion caused by different names used for the same concepts. How is DDD relevant for a skill game? How is DDD relevant for a skill game? Most of the time, initial versions of games are developed following these steps: Core game logic is developed. Ideas for monetizing are discovered. These ideas are implemented on top of the game layer. As the game evolves, new ideas are discovered and implemented. Core game logic is developed. Ideas for monetizing are discovered. These ideas are implemented on top of the game layer. As the game evolves, new ideas are discovered and implemented. As you’ll notice, this is an iterative process, and not all domains are known in the initial versions of the product. This leads to a software ecosystem described as a “big ball of mud” and with no ubiquitous language. This leads to the same concepts being implemented in different ways in the system. For example, payments might be handled in different ways for withdrawals and deposits. There are no defined domain events, so most of the time the data needs to be aggregated within the transactional systems, causing the analytical and transactional system boundaries to be blurred. If we adopt the DDD approach, we can create a bounded context, which makes the boundaries of each domain extremely clear. Setting such clear-cut boundaries is very important in skill game development because the context has unique technological requirements. For example, gameplay requires an always-connected system that might need to be implemented using websockets or rpc streaming, etc., while a withdrawal or deposit system can be implemented as a restful service. Similarly, the performance requirements are also different as delays in gameplay might not be acceptable but can be tolerated for other features as a trade-off for consistency. The required availability is also different for each bounded context as gameplay availability should be close to 100%, while it can be a bit lower for other features. Mixing these up can cause significant cost implications as getting 100% availability for the entire system might incur huge costs, which could have been avoided. Conclusion Conclusion Domain-driven design has such a wide scope that covering the complete process in a single article is not possible. Here we just tried to illustrate why this is an excellent approach to adopt when we are developing skill games. The approach can be adopted for any system but has significant benefits when applied to the domain of skill game development. Here are a couple of books that you can read to gain insights into in this process: ● Domain-Driven Design by Eric Evans, Addison-Wesley Domain-Driven Design by Eric Evans, Addison-Wesley ● Implementing Domain-Driven Design by Vaughn Vernon, Addison-Wesley Implementing Domain-Driven Design by Vaughn Vernon, Addison-Wesley
![Behavior-Driven Development From Scratch [101]](https://hackernoon.imgix.net/drafts/sop323q.png?auto=format&fit=max&w=3840)
