The quest for the perfect software architecture

In this series I shall dive into topics such as ORM's, automatic data object mapping, dependency injection and other staples of modern software development. I shall examine the pros and cons of each, and consider any alternative approaches that I have been able to find.

Who am I ?

I have been working as the lead developer on a medium sized architecture for several months now. Some parts are hard to follow spaghetti code, other parts are much clearer. I worked with the previous project lead to develop a new architecture that was supposed to give us structure and help us develop faster and with fewer bugs, and yet we find it cumbersome and not entirely bug free. We suspect that it may be starting to slow us down.

Maybe I am deluded, maybe I am an incorrigible dreamer, but I can't help wondering whether there isn't a better way...

The current architecture

We store our data in SQL Server. The data structure is defined in C# classes that EntityFramework uses to generate the database schema and migrations.

For faster loading and more advanced querying we store composite views of this data in a NoSQL database. Basically we use it as a glorified cache, and we have trouble keeping it up-to-date.

The cache updates and a small number of business rules are run via code that intercepts each write operation in EntityFramework.

We use HangFire to queue and run jobs that must run in the background. HangFire gives us a nice interface and automatic retries for free.

The code vaguely follows a layered architecture, but the passage of father time and several interns hasn't done it any favours.

Currently the app runs on a single server, serving a small number of users, but many apps do not have this luxury. This begs the question: What might we need to change in order to run at scale from the cloud?

In this series

This is a provisional roadmap and may change.

1. SQL ORM's and in particular the one we use: EntityFramework.

   • Querying and reading data
   • The poor performance of reading data from linked tables
   • Change tracking and why it could be bad
   • Could there be a better way?
   • Pros and cons: the bits I like and those I would rather avoid.

2. NoSQL database

   • Use as a cache and the difficulty of keeping it up to date
   • NoSQL vs SQL: could we have both in one storage provider?

3. AutoMapper

   • What it can do
   • Why is that bad?
   • Runtime mappings vs automated code generation

4. Dependency injection

   • How we use it
   • Why we use it and what we might really need it for
   • Double dependency trees
   • Alternative approaches

5. Ideas from the world of functional programming, part 1

   • Immutability
   • How to combine immutability and EntityFramework
   • How to combine immutability and AutoMapper or its alternatives

6. Ideas from the world of functional programming, part 2

   • Fun with .Select, .SelectMany, Linq and the query syntax
   • What should we inject and where?

7. Reacting to changes: events, actors and stuff

   • The need to react to certain types of changes
   • How we manage it
   • Could we use Microsoft Orleans, Akka, or something else instead?

8. What if we had to run at scale in the cloud?

   • What might we have to do differently?
   • What might we prefer to do differently?

9. Tying it all together

   • My favourite ingredients
   • A recipe for combining them

10. (some time later) How it all turned out

    • The bits we liked and the bits we didn't like
    • How we would do it if we started afresh.