Layers make Arlo a Sad Panda. They result from, and reinforce, thinking of the product in terms of technical components. They make it hard to vertical-slice the problem.
So what pattern is the architectural correlate for planning and building in vertical slices? This question makes sense on the surface, seems nonsensical once you get to details, and then, I think makes sense again once you go deep. Or maybe that’s just oxygen narcosis.
After all, building in thin vertical slices means that you’re often just adding one more thin aspect into each of 15 methods, then refactoring 4 of them. Isn’t architecture supposed to mean that you make each change in only one place?
But step back. What is a vertical slice? It’s everything required to solve a business problem. It is an intelligent combination of data, operations on that data, and executions of those operations to provide business value.
It is, in other words, an agent or an actor. So, building in vertical slices means building one actor at a time. And loose coupling between vertical slices matches actor pattern’s independent, intelligent processes that communicate asynchronously.
So, you want to plan in thin vertical slices? Use a design that is more like actor and less like layer. Go ahead and “duplicate” code between actors (same source, but different code paths / compositions / conditions). After all, each actor is fundamentally its process and its outputs, not the code that makes it up.
Refactor domain models in to the actors as needed – if they were intelligent agents, the domain model would be their shared perception of the world and a way of communicating about it. But they’d each also have a whole bunch of other code – the stuff that describes their thinking.
Examples of such structures: HTTP servers (each agent is not only identifiable but addressable), mesh networks, almost anything written in Erlang or Minions, almost anything designed for the cloud, strongly asynchronous apps, many MVVM apps, and event-based programs. Oddly, most of the types of apps that I enjoy writing and testing.
Minions? Hadn't heard of that one, unless you mean like in the game Overlord.
[clicks through]
Oh, is this an Arlo invention?
Yup. My new language. Because, you know, everyone has to start writing a language sometime.
If nothing else, it has given me some interesting ideas which I attempt to apply in other languages.
While reading this post I kept on thinking "bounded contexts! bounded contexts!" as a way to partition vertically. Bounded Contexts are an essential part of Domain-Driven Design by Eric Evans. Udi Dahan also describes that with examples, in relation with SOA autonomous components.
I also regret that layers "reinforce … thinking of the product in terms of technical components".
ha… almost good