The best tool for the job?

Hey @shahedc! So sorry I'd missed this previously. It's been a long time since I looked at this repo apparently; don't know what I was doing in June that had me so side-tracked.

I think to answer this question, I'll talk about the top three types of problems that I see, and the toolsets that are required to solve them, which are toolsets I'm fast becoming interested (if not yet proficient) in.

I'm going to exclude C# specifically because it's in my comfort zone, though I believe it to be the best general-purpose OOP language in existence and coding in it is a joy for me.

These are in no particular order, but you asked for three so here you go.

1. Accessible Higher-Order Domain Thinking --> Functional and F# in Particular

I know that sounds like a jumble of words, but bear with me. More than ever, I see situations in which the understanding between business users and software development teams is being mangled, especially for complex and/or complicated systems.

We can certainly adhere to domain-driven design principles -- keeping our contexts separate, attempting to develop a ubiquitous language where the code reflects the way domain experts talk and think about it, ensuring we are looking at the behavior and not just passing around entities from a database, etc.

But I do think that the type of language we use here matters a great deal. C# is a wonderful strongly-typed language, but to do a lot of that domain-style thinking, you start to get a lot of cruft in terms of the syntax you use, the validation and defensive techniques that are helpful, etc. You can work to eliminate this as a team but some of that bloat is inevitable.

However, functional programming -- particularly a strongly-typed functional language -- can make this sort of code much more achievable, and much more accessible to business users themselves. For this reason, I've been getting really into F#, which I find is a wonderful way to compose types with much less cruft that are easier to read, maintain, and extend.

Two resources came onto my radar around the same time and really brought home some of the power of this model -- they are more than worth 2 hours of your time (I got a huge value even from just clicking through Scott's DDD slides):

Scott Wlaschin's fantastic blog / talk on DDD in F#
Mark Seemann's Talk Types + Properties = Software
I'm now into Scott's book Domain Modeling Made Functional and I'm not finished but can highly recommend it.

2. Need for Reactive Systems --> The Actor Model and Akka .NET

Responsiveness and availability aren't luxuries anymore -- users demand them, and competition is fierce. The Reactive Manifesto defines reactive systems as being Responsive, Resilient to failure, Elastic, and message-driven.

Your application needs to be able to scale up and down, without losing a beat, and remain tolerant in the face of all faults. The actor model -- my favorite variation of which is Akka.NET -- helps you achieve these things by embracing a paradigm that has been around for a while but is relatively new to .NET.

I gave an introduction to Akka.NET at CodeOnTheBeach earlier this year, and Petabridge has a great boot camp to get you started if you're interested.

3. Complex and Arbitrary Relationships --> Graph DBs and Neo4j.

I think our understanding of / uses for our data has largely evolved beyond where relational databases can take us. I'm seeing a lot of folks hitting problems where

Being able to speak about the data in terms of things you can model on a whiteboard is hugely helpful
Data relationships are complex beyond what any folks can understand
The understanding of how data relates is multi-faceted or evolves over time
There are gaps in our data and we want new insights when those gaps are filled in.

I think for all the use cases and many more, graph databases are going to be the future of how we talk about data, and maybe even the default way we express and model it. My current favorite graph DB is Neo4j though I'm looking forward to experimenting with CosmosDB graphs soon.

4. Honorable Mentions

...okay you know I can't limit this to just three. I tried, I really did.

Cognition-facing problems --> Azure Cognitive & Bot Services. Apps need to fundamentally interact with humans and customers in a more relatable way. They need to have real-time context and User Experience will give way to human experience without the abstraction. I think some absolutely amazing things are happening with Azure Cognitive Services and the Bot Framework, and I'm excited to explore them.
Event-based Problems --> Event-based Approaches and Event Sourcing. This one's been around for a bit, but I still see folks opting for a relational database when they want to be able to replay events, or have auditing build into the system, or be able to test complex combinations of things that happen. Yet they still shoe-horn this data into a relational table, run bulky processes, intermingle the system's reads and writes, and don't think about the pieces of data flowing through their system as a series of events. Event-based approaches that treat these events as core components of the system to be modeled and persisted are going to save folks a world of time once they really catch on (and in many ways they already have).

This was a fun one to write up and think about. Thanks @shahedc!

SeanKilleen / ama