Tölvumál - 01.11.2015, Blaðsíða 7

7
Onion Architecture.
Onion architecture is key to guaranteeing longevity of software systems
as the elements of software that become obsolete are externalized and
are therefore easily replaceable. This is the prime reason why we at
Valitor chose this architecture. An example demonstrating the strength
of the combination of this architecture and SOLID is that when we need
to change databases, only one line of code needs to be removed from
the codebase to completely cut the previous database implementation
from the system. Also, adding a new database to a system, only one
line of code needs to be added. Of course, an implementation must
make queries to the relevant database. However, that code resides
entirely within an assembly that becomes part of the system by adding
one line of code. The same applies to all infrastructure.
The fact that the application core consists almost entirely of interfaces,
is the key to how well this architecture works with SOLID. This becomes
apparent when applying the Dependency Inversion Principles, where
interface implementations can be injected into classes that make use of
them. Using interfaces in this manner also helps developers when
creating unit tests using Test Driven Development because
dependencies can be easily be mocked or stubbed.
TEST DRIVEN DEVELOPMENT
TDD is a “test first” methodology that has been around for several years
now. Red-green-refactor is the pattern used when developing software
with TDD. The below list explains the rationale behind red-green-
refactor:
• Red means write a unit test that fails
• Green means only write enough application code to make the
previous test work
• Refactor means clean up the application code and allow
patterns to evolve
It is a good practice to create small and cohesive unit tests instead of
large test-all tests. The reason is simply that it is easier to maintain small
tests and more importantly to determine what the problem is when
changes to application code break existing tests. It is also important to
use naming conventions that easily allow developers to indicate what
requirement the test is meant to address.
TDD has been criticized for its potential impact on software system
design. If no other design processes are used, this can become a
problem because when a design has not been verified there is no way
to determine whether the resulting design is good or bad. By using
SOLID principles in conjunction with TDD the impact that TDD has on
software design is eliminated. Much effort is put into the design phase
of all new systems at Valitor. All design artefacts undergo peer review
and validation is completed by creating a vertical slice. This eliminates
any risk of TDD guiding developers to bad design.
A case study was made in-house on the impact TDD has on the
number of defects in a system. When developing our merchant
boarding system, one system component was developed using TDD
and another component without using TDD. The result was that the
component that was developed using TDD had 60% fewer defects.
This is in line with case studies we read when we evaluated whether to
use TDD or not.
SUMMARY
Using strong architecture along with good design and testing processes
is crucial to create outstanding software that will stand the test of time.
After using these practices for the past 4 years at Valitor, we are
experiencing software systems that are much easier to maintain and
have fewer defects than we had before.
The combination of SOLID principles and the Onion Architecture
tackles volatility within a single system. This applies both for volatility in
the individual elements of the system infrastructure, and volatility in the
problem domain itself.
Vital to achieving the level of success Valitor realized in adopting these
methodologies is active training for software developers and to
incorporate in-code-review processes that analyse how the code base
conforms to the practices in use. Code review is also a very good tool
to initiate a conversation between developers about the practices
discussed in this article.
1 Reference: http://jeffreypalermo.com/blog/the-onion-architecture-part-1/