3 ms·
There's also more than one way to carve up the architecture. I do think that we humans need slices in order to mentally compartmentalize and be able to work wit
by mumblemumble 7y ago
There's also more than one way to carve up the architecture. I do think that we humans need slices in order to mentally compartmentalize and be able to work with manageable bits. But there's no reason I can think of to systematically prefer vertical slices or horizontal slices.
Horizontal slices give you something like the classic monolithic three-layer architecture, and vertical slices give you more of a component-based approach.
The big trick is to know which approach you're using, and stick to it. In a layered architecture, you absolutely do not skip layers, but it's generally fine to have one layer talk to pretty much any part of a neighboring layer. In a component-oriented architecture, it's really not a big deal IME to let controllers talk directly to the database, just so long as you never let one component directly access another component's schema. You get data out of other components by talking to their public interfaces.
As long as you color within those lines, things won't get too tangled. If you're really worried, I suppose you could try doing both vertical and horizontal splits, but my impression is that that always places the application at risk of collapsing under the weight of its own bureaucracy.
- bluGill 7y agoI generally think you have several levels of architecture.you might go vertical at the high level and then delegate each slice to more junior architects who do different things in their slice. Of course this depends on the size of the project too.