How to apply the Onion Architecture

I got a lot of questions about how to apply the Onion Architecture to particular situations. In this episode, I try to answer it with a specific example.


►► Audio, Video, and Transcript available: https://lispcast.com/how-to-apply-the...
►► Subscribe on iTunes: https://itunes.apple.com/us/podcast/t...

Transcript

I answer some tough questions about the onion architecture. Hi, my name is Eric Normand and these are my thoughts on functional programming. This is season two and I hope to up the production quality that I had in the last season.

Let's get right into it. A few episodes back I introduced something that's called the onion architecture. I introduce it, meaning I explained it. Just real quick, the onion architecture is the layered architecture where you have your core domain implemented in a functional way in the middle.

It's layers like an onion. Around that you have your business rules, also functional. Then finally, the last layer is this interaction layer. This is the layer where all the actions happen. This is the layer that talks to the database. It gets Web requests and makes other API calls.

This is an architectural pattern that you can use to have a functional-style architecture. After I posted that, I got a lot of variations on the same question, which is, "How do I make decisions in my domain model that then result in taking different actions in the outer layer?"

The idea is, if you weren't going to architect this, let's say you just had a very basic, straight forward implementation. It's imperative. You would make an API call. Based on the results of that, you make some decision. Then you either call API A or you call API B. That's the end. The logic of what you do is mixed in with the actions that you take.

How do you extract that out into something that you can call an Onion Architecture? Right. That is the real question that people have. I have to say, I got a couple of examples of what people wanted to turn into an Onion Architecture.

My first thought was, there's not enough logic in it. There's not enough business rules. There's not enough domain in it to warrant coming up with different layers. Then I thought, "No, these are just simple examples that they're giving, so let's do it right." Here's an example that someone gave me. I should look up the name so I can reference them.

This is Andrew. Andrew, thanks for the question. In his example, you are implementing a web endpoint. This endpoint is for information about music albums. In the endpoint, you want to include images of the artists who worked on the album.

There's some constraints. You need to have as many images as you can, up to five. Things like that. The problem is, there's a lot of logic about...For instance, if there's more than one artist on the album. It's a compilation CD and you have a song from this artist and a song form that artist, you want to have one image from each artist. Not five of the first person.