What is the universal process pattern?

Part 3 of the functional architecture series. The universal process pattern is a schematic representation of software. For a software process to be useful, it needs input, it needs to calculate something from that input, and it needs to have some output or effect on the world.

Transcript

Eric Normand: What is the universal process pattern? Hi, my name is Eric Normand. These are my thoughts on functional programming.

There is a book written by Zach Tellman called the "Elements of Clojure." In that book, he talks about what a process is, and that a process requires three things to be useful. You can have a process without them, but then it's not useful on its own.

The three things are, you need a way to accept input, a way to transform that input into an answer, do some calculation, and then send an output, have some effect on the world. It's a good book. You should read it. A great book, actually.

I want to talk about it as it relates to architecture. If we look at this process pattern as a schematic for how our software should behave, it's going to have this input. This is any kind of input. This could be user input. It could be web requests coming in. It could be stuff coming off of a cue. That's input.

Then, there's the output which is the effects it's having on the world. It's sending emails. It's responding to the web requests. It's displaying stuff on the screen for the user. Inside, there is some kind of calculation going on.

The way that this is designed is it's done in a functional way. It's done using a pure calculation, no side effects because all the side effects are captured in that output.

You can look at your software this way. If it's just a monolith, it would be one big process just accepting input, transforming it, having an output. Or it could be, in a service-oriented or you might call it a microservices system. You would have a bunch of these little processes running. They can communicate. Part of the output could be a message sent to a different service.

This is a useful way of looking at your software, from a functional point of view. You push the input and output. You push the effects to the edges. It's defined as this is the input, this is the output, but inside you have a functional transformation, some kind of calculation from that input to the output.

https://twitter.com/ericnormand/status/1079769614253469696

This is my third thought on functional architecture. I don't think this thought is that deep. I thought it could be helpful to have this schema in mind, this schematic for how, if you had to draw it on the board because a lot of architecture is just drawing.

If you're drawing it on a whiteboard, you could draw a box with arrows going in and arrows going out. What are the inputs? What are the outputs? That would help you organize the ideas and put some kind of structure to them, some kind of architecture to how to lay it out as opposed to, not considering those inputs and outputs separately.

That's what really makes it functional, is that if those are actions the inputs and outputs they're not controlled by the process. The outputs are, but the inputs aren't. The outputs, once they leave the process, they are not controlled anymore.

If you look at it this way, you're actually looking at it from a functional point of view. It is very similar to how the onion architecture is structured, that you have this layer on the outside that is doing all the input and output, all the reading and writing, all of the effects.

This is the third in this series of architecture thoughts. I don't consider this that deep, but it's been helpful for me to see a way to draw these things in a small way. Instead of having to draw a whole onion thing, you just draw these little boxes with lines and arrows. Awesome.

If you'd like to get in touch with me, you want to discuss it, I'd love to hear more thoughts on functional architecture because it's an important topic. I don't think we have good enough literature, even in informal blog literature about it.

If you have a thought, if you've read a thought before on this, come on, share it. Share it with me. Share it with others. Put it in the comments.

You can find me on LinkedIn, just search for Eric Normand and Clojure, if you can't find me with just Eric Normand. On Twitter, I'm @ericnormand. I love to get into Twitter discussions. Then, you can email me if it's a longer form thing, I'm eric@lispcast.com.

Please subscribe and like, it really helps me out. Helps support all these thoughts if you find them interesting. It's something that would be very helpful. Great, thank you so much. See you next time.