Reflections on software design, architecture, delivery.

One of the strengths of Workflows as an abstraction in domain modelling is their one-to-one mapping to collaborative modelling techniques like EventStorming. So that in principles we could model requirements collaboratively with our domain experts, and then map that model one-to-one with our code. If we understand this powerful connection, we can then also leverage Workflows to model data structures and state transitions in the context of Event Driven Architectures and EventStorming.

I was reading the Effect documentation, there's quite a buzz about it right now. I totally see where they're coming from and where they're going, BUT. For one thing, I'm not sure they add any original or important abstraction to functional programming, compared to, say, using fp-ts. Actually, adding custom abstractions is distracting from the original theoretical concepts of functional programming; if we start calling things with other names that's like muddling the pure waters of algebra.

In functional programming languages, like F#, or in TypeScript using fp-ts, it's possible to achieve seamless composability of functions by controlling, manipulating and matching outputs with inputs. Most of functional programming trickeries serve actually this purpose, and the resulting composability opens the door to a treasure chest of patterns (see the Master Scott Wlaschin blog and book for this).