Functional programming in the small works great. Things start to get shaky when there are many services and teams involved, something that is becoming more and more common with large distributed systems.

The value of the tools we know and love, like static typing and powerful type systems, decreases as the system gets larger and the number of components involved increases. In an industry that often praises fast paced releases (the ultimate startup motto: ship fast or die trying), this becomes even more problematic.

How do we get to enforce correctness and reap the benefits of FP, when we can’t statically check the entire system? When we have to cross the boundaries of a single compilation unit? Our beautifully crafted types aren’t going to cut it.

This is where Software Architecture comes in. A well architected system is not some stroke of genius: often the opposite. Good software architecture means you still get to reason about the whole thing and make changes to separate components without affecting others. While we can afford some complexity in the small (ie. fancy types), complexity in the large can break a project. As much as we wish we could solve these issues with static typing or formal verification, part of the solution is definitely non-technical. Conversations among all parties involved (yes, business people included) are key for good architecture to emerge.

We’ll talk about what I found to be the more effective techniques to architecture such large systems: event sourcing, cqrs and the over arching philosophy of Domain Driven Design.