Vertical Slice Architecture isn't technical

[@bwaidelich]

Great, as usual! Just a little comment: I read the draft of Alistair Cockburns book "Hexagonal Architecture Explained" the other day and the pattern was originally in fact meant to implement Vertical Slice Architecture apparently (I get your point though, that it's definitely not the only implementation of it)

[@Timelog88]

Same for the book clean architecture. I saw Jimmy Boggard's talk about vertical slice architecture before reading clean architecture, but when I read it, it was basically the same. Sometimes I wonder how our industry has misinterpreted the meaning of all these things so much.

[@AlexanderZeitler]

Jimmy Bogard, now that content creators "teach" VSA: "Look How They Massacred My Boy". Great video, again.

[@jonashansen2512]

Just realized I've been doing vertical slices intuitively. Just made more sense and keeping naming aligned with the business lingo just seems logical and practical once the business is understood from a birds eye perspective

[@AndresPineros-k9t]

I've been telling the places where I work to always split the business and services vertically and not horizontally. Horizontal splits of the capabilities are useful to keep things dry, but they have to be REALLY well designed, which is hard. I love that this term is about to become an industry thing.

[@CodeOpinion]

And it's easier to move stuff around when it's first tackled horizontally than vertically. At least in my experience.

[@robotrabbit5817]

Great content. Thanks clarifying the vertical slice further. Piece by piece

[@CodeOpinion]

Glad it was helpful!

[@BlindVirtuoso]

Great as always. Thanks Derek.

[@CodeOpinion]

Thanks again!

[@PatricSjoeoe]

I love the idea of vertical slices. And it works.

[@jrgalyen]

@Derek Comartin - This hits on a key principle of VSA. But no. Business Capabilities are not what makes a VSA. At least not alone The way communication is organized affects architecture producing a VSA. And the way Business Capabilities are organized affects communication Conway’s Law! Simple as that Team organization & full slice development based on seperation of business capabilities affects technical architecture into VSA

[@CodeOpinion]

Yes absolutely how you communicate is important. I agree about Conways law, which means you'll build/structure a system based on the communication of the org, which might not be what you actually want in the system, but yes it will happen.

[@z0nx]

So how does one define the boundaries? Where do the events go, which domains store it? Sometimes that may be ambiguous, where each system may need different information of the same entity. Does anybody have some kind of process to figure this out? Is everybody EventStorming for this?

[@krccmsitp2884]

"different information of the same entity" --> think that over, is it really the same entity then?

[@z0nx]

@@krccmsitp2884 something that may have the same name, diffent context

[@marcom.]

For some reason, there's yet another new topic being bandied about. A German architecture channel has just shown the latest video on this very topic. But it doesn't really help us any further. How many more years do we want to talk about software architectures and new buzzwords instead of finally getting down to brass tacks and defining how things work best? And what's the difference between vertical slices and bounded contexts?

[@gpapadopoulos]

Because the only constant with software is change.

[@gpapadopoulos]

It might be a case that a specific software architecture doesn't even work with your particular situation. And there always be a need for fresh, new approaches.

[@CodeOpinion]

"But it doesn't really help us any further.". I'll ask a rhetorical question. What's REST? What's Agile? What's DevOps? What's CQRS? The list goes on. Because these terms at one point had a meaning that got turned into something completely different that's now the defacto definition (semantic diffusion).

[@marcom.]

@@CodeOpinion I don't think like you and some others here do. I've been involved with software architectures for 25 years now, and for some time now it's really just old wine in new bottles. And on top of that, there's an eternal debate about whether and when to create microservices and when not to. The real point is this: We want loose coupling, high cohesion, good modularization, clean boundaries, clean layers and interfaces, resilience and, ultimately, the freedom to package and deploy the artefacts in many ways. In my opinion, there are enough concrete approaches to combine and create an overall architecture that is viable for most business problems. But it's just much easier and more lucrative to just talk about individual aspects and throw a lot of puzzle pieces over the fence. We should finally grow up in software development and earn the title of beeing a real engineer.

[@CodeOpinion]

I'm curious if you watched any of my other videos? My guess is no, because the vast majority of my videos are all outlining everything you mentioned in your comment. This specific video the TLDR is about high functional cohesion at it's core. I'm curious what you expected in a 10 minute video? That I cover all of the aspects you listed? Those indeed are all the puzzle pieces that are not going to be covered in a 10 minute video. The entirety of my channel does though.