Tölvumál - 01.11.2015, Page 6

6
In recent years software companies have put increasing emphasis on
software design. When good software design practices are put in
place, the result is higher software quality. A basis for good practices is
the use of a common foundation for design language and diagrams.
The reason is that design artefacts are a great tool to communicate
design decisions, both within a development team, as well as between
teams. This is becoming more important as we enter the age of micro
services.
Software architects should employ designs that maximize system
lifetime. Furthermore, they should bear in mind that the infrastructure
used to develop the initial system will become obsolete as time passes,
and must therefore be easily replaceable. This perspective along with
good design and the correct architecture is key to avoiding the dreaded
Clean-Slate Syndrome, where systems have become so difficult to
maintain that companies are forced to abandon them and build new
ones.
In 2011 Valitor set its sights on providing acquiring services for
merchants in the UK market. To support projected growth, both in
number of merchants as well as transactions, new software systems
had to be developed.
Before work began on developing these systems, the technical leads
initiated a search for the best possible methods for system design,
architecture and unit testing. After exploring multiple architecture and
design principles it was decided that a combination of SOLID principles,
the Onion Architecture and Test Driven Development (TDD) would
comprise the methodology of choice.
In this article I will briefly describe SOLID, Onion Architecture and TDD
and the impact they had on Valitor’s software development. Those
interested in learning more about these practices can easily find a
variety of sources on the World Wide Web.
SOLID PRINCIPLES
SOLID involves five principles that encourage the design of software
that is easier to maintain, extend and provides greater software
flexibility. Furthermore, code created using SOLID is very testable. The
SOLID acronym stands for the following principles [Reference: Agile
Principles, Patterns and Practices in C#]:
• Single Responsibility Principle: A class should have only one
reason to change.
• Open/Closed Principle: Software entities should be open for
extension, but closed for modification.
• Liskov Substitution Principle: Subtypes must be substitut-
able for their base types.
• Interface Segregation Principle: Clients should not be forced
to depend on methods they do not use.
• Dependency Inversion Principle: Abstractions should not
depend upon details. Details should depend upon abstractions.
Design complexity is one of the characteristics of SOLID principles and
that is what we experienced in our software development. Systems
created using SOLID had significantly less complexity in code as
complexity shifts from the code into the software design. The code has
fewer IF and SWITCH statements, has smaller classes, and more
importantly, high cohesion and loose coupling between classes. The
emphasis that SOLID has on interfaces is key to creating good software.
Decoupling implementation details means that implementations of
interfaces can be changed without changing high level components.
This focus on interfaces is also fundamental to how powerful the
combination of SOLID and Onion Architecture is.
ONION ARCHITECTURE
Onion Architecture was created by Jeffrey Palermo in 2008. The
purpose of this architecture pattern is to externalize infrastructure and
write adapter code so that the infrastructure does not become tightly
coupled.
Onion Architecture is a semi-closed architecture that uses interfaces
extensively as means to decouple classes and externalize infrastructure.
Instead of building systems on top of a specific data store or some
other technology, the system is built around the domain models.
Domain models are the centre of the onion and the layers around it that
belong to the application core, contain only interfaces. At Valitor a layer
was added, as part of the application core, which contains only pure
business logic and has no references to any third party library or any
external infrastructure that could become obsolete in the future. An
example of business logic residing in this layer are validation and
business rules run on merchant applications.
STANDING ON SOLID
GROUND
Hlynur Jóhannsson, Chief Software Architect, Valitor