I've gotten several questions about how to do X or Y in the Onion Architecture. It seems like giving the architecture a name has miscommunicated how simple it is. It's just function calls that at some point are all calculations. In this episode, I try to deconstruct what makes the onion architecture work. Spoiler: it's just function calls. ►► Audio, Video, and Transcript available:
►► Subscribe on iTunes:
Transcript
In the Onion Architecture, how do you make business decisions that rely on information from actions? I get this question a lot, especially when I bring up Onion Architecture in more of these episodes. In this episode, I am going to answer it for everyone. My name is Eric Normand. I help people thrive with functional programming.
The Onion Architecture is a way of structuring your application with actions on the outside. These are called the interaction layer because if you're interacting with the world you really have your enactions. You're receiving requests from the outside. You're making API requests yourself.
You're reading from the database. You're doing a lot of IO, having effects on the world or sending emails. You're making lights blink. Whatever your software does. That's all in the interaction layer.
Inside you have a nice, pure set of layers that are all about calculations. I like to divide them up in a certain way. I like to put the business rules as my first layer inside. Inside of that, a domain layer.
Both of those, it doesn't matter how you divide it up, especially for this discussion. They're calculations. They're pure. They are not based on stuff from the outside. They have no effect on the outside. They're like little brain that you can give it questions and it will answer their questions. It's making decisions, basically.
You got this calculations making decisions, business decision, even simple domain decisions. The actions are doing stuff like fetching stuff from the database. Sending data to an API.
Here's the question that I get a lot, "If you've got the Onion Architecture, how do you make decisions that should be calculations like how many times to retry an API? If it fails the first time, do you retry?" That's a decision your software has to make. How do you have a calculation that decides that it needs to have more information from the database?
It says OK. I've done a bunch of stuff. Now I know, I need this more information. It can't get it itself. How does that information get up to the higher layer so that the higher layer can get it and then give it back to it? It's weird. It starts to sound like a really difficult problem.
I said, "I've gotten this question several times in different forms." It's a thing that I've caused a confusion I've caused in how I've explained it. I'm using language to try to talk about them as separate layers. People aren't really used to thinking in layers.
I'm going to try to pick it apart and put it back together with a new explanation. When I talk about layers, I'm talking about functions in your language, they're either calculations or actions. Functions calling other functions. Function A calls function B.
There is a relationship there. If you draw all of the relationships between functions, and what functions those functions call, then what functions of those function calls. You make sure all of the arrows are pointing down. You have the stuff that nothing calls up at the top that would be like your main.
Then you have the stuff that calls, but nothing else called and you can just arrange them all. At some point, you could draw a line and say, "Everything below this line is calculations." Because a calculation cannot call an action. If a calculation called an action, it's not a calculation.
By definition, calculations cannot call anything above that line. You could draw a line and say, "This stuff down here is all calculations." The stuff above is all actions.
That's what I mean by the layers. It's all just function calls, it's not like some kind of protocol for communicating and getting information like, "Here's a decision I need you to make," so you give me the answer, and then I ask you what I do with that answer.
0 Comments