There are different types of complexity in the IT system. Understanding the types of complexities we face will help us make better design and architectural decisions. Adapt techniques to the problems we want to solve.
Domain complexity
Domain complexity, as the name suggests, is the complexity of the business problem that a given system is to solve. For example, we create a system in which you can insure real estate. Realty arrangements have many conditions that only insurers know. A programmer who was not previously involved in the insurance industry will be initially overwhelmed with the number of dependency rules and terminology applicable in this industry.
Failure to deal with this type of complexity causes:
- High Coupling
- Overengeering
- Team member rotation
Failure to understand the domain often results in the fact that even a greenfield project quickly becomes hard to maintain.
How to fight with domain complexity?
A set of proven techniques in battle is Domain Driven Design described by Eric Evans. Strategic patterns are especially noteworthy because they provide tools on how to communicate with people from business. It allows us to gain knowledge about business processes. Extract the core of the system. Finding a shallow and deep places in system.
Accidencal complexity
Random sensitivity is present in every IT system. It is especially visible in the legacy in systems. Each of us probably had a simple task to do. For example, add one field to the UI. We evaluate such tasks for one manday. We go to the place in the code where we have to add this field. It turns out that the code is incomprehensible and operates on reflection and dynamic types. Somehow we managed to do it in one manday. The next day, the tester tells us that we’ve broken something elsewhere. Combination and repair takes another mandays two days. We are finally done with the tasks.
Accidental complexity contributed to not deliver task on time.
How to fight Accidencal complexity?
We should fight against accidental complexity first of all with Refactoring. In line with the “Scout Boy” rule. If we go into some code we become the better one. In the future there will be an entry on “Countinous Refactoring” where this topic will be more relevant. Another tool to combat this type of complexity is abstraction. Sometimes a good technique is to cut yourself off the legacy code with create new module. In this new module we will create new code in good way. For the old legacy code we will create abstraction and use this abstraction in our new module.
Summary
Each IT project is different, in some we have a complex domain, and in another problem is randomness. Sometimes we have both. We already know that we can fight a complex domain with Domain Driven Design. In case of accidental complexity we use modularity and refactoring. It is worth educating your knowledge in those topics. Introducing the discussed elements to your project so that the business earns more and the developers have a more pleasant work.
Top comments (0)