Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
The best tool for the job? #6
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):
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.
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
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.
This was a fun one to write up and think about. Thanks @shahedc!