Clean architecture

Under construction
image by studiogstock - www.freepik.com

Clean architecture describes concepts, patterns, and conventions that ensure the maintainability and expandability of large projects. Sticking to clean architecture is mandatory.

Table of contents


Scope of clean architecture rules

Clean architecture rules are mandatory for a big software project. Contrary to clean code rules, clean architecture is less a personal choice. Rather, the ideal architecture is intrinsic to the problem to be solved.

Clean architecture contains concepts, patterns and conventions.

Concepts are general rules that help organize large projects and select the right patterns.

Software design patterns are general solutions to commonly occurring problems in software design. You need to adapt them to your problem.

Conventions are strategies and solutions that are specific to your problem. Approaching similar problems with the same strategies increases development speed and project mainainability.

It is up to the programmers to find something close to the ideal solution. In the end, many patterns work, however some better than others. Programmers that ignore patterns are more likely to use unsuitable ones.


Concepts

DonĀ“t repeat yourself

The most important concept. Never write the almost same code twice. It is always a sign of bad architecture because:

  • Code should be as short as possible. The longer your code, the more mistakes can hide. Repeating yourself equals to longer code.
  • You might need to change your code. Having the same code at different places increases the risk that you forget to change it in all places.

KISS

Keep it stupid simple. Always prefer the most readable, clear solution. That is not necessarily the shortest code.

Loose coupling, the law of Demeter

A loosely coupled system is one in which each of its components has little or no knowledge of other separate components’ definitions.

Follow this law. To do this, make clear for every class whether it is an object or a data structure. One is the opposite of the other. Avoid mixed forms.

Data structures are better when you know the data, yet not what you might do with it. Example: mob coordinates.

Objects are better when you know what to do with something, but not what kinds of somethings there are. Example: mob types.

Collection of data structures

To qualify as a data structure, a class should have no methods. It should contain public data. That data is processed with external methods, e.g., from static processor classes.

Advantage: Easy to add new methods that process data.

Disadvantage: It is hard to change the data structure because every method may need adaption.

Collection of objects

To qualify as an object, a class should hide its data. It should only provide methods that work on that internal data.

Advantage: Easy to add new kind of objects as long as the implement the methods.

Disadvantage: It is hard to add new methods because they need to be added to every object.


Patterns

This is not a list of all software design patterns. Rather it comments on why and why not certain patterns are used in the MMORPG project. If you are actually interested in a list of all software design patterns, read here.

Singleton pattern

The singleton pattern should be avoided because it increases technical debt. Especially it should never be used to create a simple globals access point.


Conventions

Static class

A static class can be used for a class that is a collection of related methods. These classes have the ending “Processor”, e.g., MathProcessor. Such Processor classes are ideal for processing data structures.

Another use is the collection of constants.

Constants, globals, configurables

//Constants
//initialized at compile time, values that never change
//values are the same for every project
public static class Constants
{
    public const int CONSTANT_VALUE = 12;    
}


//Globals
//initialized at runtime, cannot change later at runtime
//values that are the same for every class in a namespace
namespace xyz
{
    public class Globals
    {
        public static readonly int globalValue = 12;   
    }
}

//Configurables
//initialized at runtime, cannot change later at runtime
//values that are the same for every instance of a single class
public class xyz
{
    //class variables
    
    #region Configurables
    private static readonly int configurableValue = 12;
    #endregion
    
    //class constructor
    
    //class methods
}

Checklist

under construction


Server Sid
Server Sid

“Clean architecture is mandatory to prevent technical debt in large projects.”

(Last Updated on May 14, 2021)

Leave a comment

Your email address will not be published.