Coffee Grinders

I wrote about something I’ve been thinking about quite a bit over the past year, namely the fallacy of modeling something as a transaction that is really a process. This thinking has led me to some disparate but related modeling patterns which as a placeholder I’m referring to as “Coffee Grinders”.

It’s a bit of a longer post with some code samples and explanations which may or may not make much sense to people, but in any case I hope it will spark some interesting discussion. I’m especially curious about prior art and related patterns that people may have come across.

2 Likes

Thanks, good food for thought!

The transactional fallacy is when you model something as a transaction while it really is a process. In Clojure we are perhaps even more susceptible to this because we tend to model things simply as functions. A web service call, a database import, a HTTP handler which in turn consults several microservices, they all just become functions. When you call such a function all you can do is wait for it to finish or blow up.

I watched Avdi Grimm’s talk, and it’s awesome. However, bringing his ideas fully to Clojure development maybe a complication as they seem to be somewhat redundant within Clojure’s paradigm.

To see distinction between momentary, and continuous things is important. That is certainly an important lesson to take from his talk. However, in Clojure terms it still looks like this:
Ask yourself about how granular you need your data stages (states) to be, and write your functions accordingly. Which is not a new idea, anyway :slight_smile:

As I see it, one of the Clojure’s advantages is emphasis on data in modeling: here’s starting point, here’s what you need to get, now just insert transformations inbetween. It is exactly what it makes architecture planning in Clojure so much easier, and way more natural then with majority of other languages.

And from this perspective distinction between transaction, and process fades.

A process is (I suppose) a continuous application of a function(s) producing Nth state from (N-1)nth, maybe invloving some sort of logically unified chained dispatching from fn to fn based on state properties at every step. Transaction is probably just one-step application of a function. Simply functions, nevertheless if your state keeps information so that it allows you to distinguish between stages you’ll be fine adding progress bar, or resuming after failure with ease.

Grimm tries to solve issues brought by actions-first approach, I believe.

I’ve been enjoying your Advent 2019 articles, Arne. Thank you! Coffee Grinders look a lot like automatons to me.

1 Like

I wrote a follow-up post that’s a bit more concrete and practical. https://lambdaisland.com/p/coffee-grinders-2

3 Likes