Designing for change with Vertical Slice Architecture - Chris Sainty - NDC London 2024

[@girts.strazdins]

One of the best talks I have ever seen on software architecture! Good message, good delivery.

[@egorgoryachkin8442]

Great talk! You feel that it's made by a true practitioner, and what i really enjoyed, is sense of humor added to the conversation about serios things, actually))

[@AbdullahKhan-hz7yr]

Great talk, Chris. However, I wish you had touched on some common practical scenarios, such as the best practices for features that interact with similar data-using the same table as an example. In microservice architecture, this is big no no, but it appears not to be so strict in the vertical slice approach?

[@seethruhead7119]

if two slices use the same table you've now coupled them which is entirely opposed to the point of slices no?

[@jirinovotny9704]

I liked the disclaimer at 46:40. However, the Handle method must be marked async, and the SingleOrDefaultAsync extension method should rather be used to actually compile the code. Other than that, I like the idea of vertical slices and I worked on projects that had grown into huge sizes and suffered from what Chris described. I just would love to see some examples or some discussion around good practices of how to layout the features and their borders because it is a pretty vague term tbh. I also am quite curious about what the design decision-making will be for huge projects when a change order arrives with a new feature that overlaps various existing features. It can become pretty hard to tell where one feature ends and another one begins. Or do you create a new one? This can become pretty messy quite quickly if it's affecting existing views or other end-user experiences.

[@artemvolsh387]

yep, also the method itself should be async 😅 *just for the gig

[@awright18]

It's always nice to see people preaching the same gospel that I practice. Absolutely agree one of the biggest problems with code that lasts for years is the desire to share code. Sharing code makes it fragile and can cause very difficult to debug issues when the shared code is inevitably changed.

[@micknamens8659]

(If you don't listen until the end) it sounds like going from one extreme (no code duplicates) to the other (no code sharing). IMO as always the truth lays in the middle. There is nothing wrong with sharing code in the sense of calling functions with well defined and understood semantics. Of course you're only allowed to change this semantics if this is demanded by changing business rules. There are two different ways to define the semantics of a function: 1. Event based: whenever a specific situation occurs, this function must be called (as a signal) to handle this situation. The caller doesn't know what happens. 2. Intend based: to achieve some specific effect or result, you can call this function

[@simoonberrger7325]

yes, yes a thousand time. cant tell how often i had to fight these fights and untangling some super duper "architectures" so that one can work with them again

[@NilsElHimoud]

Thanks for the paradigm shift with regard to code duplication

[@NekoApril]

There certainly are some interesting ideas here but I do have quite a few concerns. 1) I feel like this approach will just end up clunkily reimplementing the layers in each of the code paths, and after a few rounds of refactoring you'll eventually just get back to having a layered architecture but without the structure getting there intentionally can give you. 2) This feels like app-wide security would quickly become a nightmare without very good (and complicated) access rules on the DB. Sure, each vertical could be examined independently, but they would also _have_ to be examined independently. 3) I don't think this would solve the problem the presenter is saying it will. If your team is breaking Open/Closed to do hacky fixes on a class/interface level, there's basically no chance they won't on the level of a vertical. I do think this could be useful to separate different usage patterns for an app, or within a layer, for example, but trying to force each feature to go down isolated (or near isolated) codepaths seems a tad overeager to me.

[@Dmitry-Moiseenko]

Great talk, thank you!

[@ralmslb]

17:20 I don't agree with this part. This is bad design. No reason to be placing Repairs related stuff on a service dedicated to "engineers", otherwise from that mentality, all services would have everything.

Thing I'm most interested in such architectures is how to implement 'shared' business logic. It's not a problem to duplicate code. The problem is not to forget to implement a feature which appears in multiple slices. Imagine needing to send email whenever repair is finished (from whichever slice).

[@VoroninPavel]

But should not this be a separate module then?

[@kevinlloyd9507]

Domain events and the corresponding handler seem like a good solution to this problem.

[@Rick104547]

Sending an email after a repair is finished should be its own slice I think and it can act upon an repair changed event. As a bonus since sending a email is asynchronous by nature your other features don't have to wait for it to finish.

[@juancarlosbaezpozos9353]

Where are the code examples; it's very easy to say "I am going to save the world" but you never showed me an example of the real world !!!!!!

[@ralmslb]

Honestly, I see a lot of issues with this architecture: - High potential for general solution inconsistencies from an end user or consumer point of view. - Possible data corruption due to each vertical slice handling things differently, for example, validating a user authentication before performing X Action or applying changes to X table on a DB. - The code duplication can result on a bug or issues to need to be fixed on every single slice. Meaning that unit testing will also need to be duplicated. - Incentivizes code regurgitation, since you know there is almost 0 impact on what you deliver on each, resulting on potential poor quality long term from rushed feature push from the business. - Engineers training or adaptation will be a nightmare. Engineers can start working fast on a slice (since they can code it however they feel like it), but that will mean they will have 0 clues on how to work on the other slices. Instead of training an engineer on an architecture, they will need to train on 10, 20, 50, 100 slices. In my eyes, this architecture is a sign of devs giving up on fighting back poor planned software releases and accepting business leaders pushing for rushed features and functionality, instead of good, tested software. Considering this I wonder if mixing a vertical slicing architecture on top of a couple core layers won't make more sense (like user management, DB access, etc, that have generic methods to perform operations). This architecture short term looks pretty and such, but long term looks horrible and will result on a total mess. Also, as a last note, just running away from Services in my eyes, tells me that either all the solutions that this person worked were poorly planed or he only ran into already existing poorly developed projects. Services provide a lot of benefits in my eyes, preventing future problems. Coming up with this architecture, just seems to be a way to get a justification to vomit code at will.

[@Ry4nWTF]

just place cross concern stuff (auth, 3rd party junk) in something that is shared, but keep each feature separate

[@joeedh]

​@Ry4nWTF But then it wouldn't be vertical slice architecture :) Seriously this is a 70s level view of software.

[@marcotroster8247]

You're not designing hardware, you're designing SOFTWARE. Of course the most important property of your system design needs to be adaptability. Drop your ego and duplicate stuff. It's not too bad if you make your code look like proper English sentences to tell a story. Turns out people who can read English are able to work with the codebase.

[@kevinlloyd9507]

Towards the end of the talk he discussed proper ways to share logic. Mainly in your domain model. That bit was a little unclear, your domain model is shared. That's where validation and things like that would live.

[@joeedh]

@@marcotroster8247 The inflexibility of excessive duplication is its number one drawback, but let's pretend it's the opposite to defend an obvious corporate consultancy grift. How smart of you.

[@ForgottenKnight1]

29:30 - Sonar users will probably not agree with you entirely on this one, because in that context duplication = bad. I've seen enough projects with bad abstractions, bad sharing of code, super high coupling and just bad design, just for the sake of "reducing duplication". F the rest, the Sonar reports are more important. Let's just say those projects sucked.

[@marcotroster8247]

Tbh, I've been working on horrific codebases like websites loading for several minutes because some guy thought "let's not use database joins and request each id separately". Sonar reports didn't find any of those issues. Not even functions with 20 parameters or functions with 3k lines. It just found stuff like "there might be a security hole because you didn't explicitly define the encoding". Let's agree that Sonar is trash and people trusting it are noobs, no offense.

[@Rick104547]

Agree, I find that just relying on the full set of .NET analyzers (which is not on by default btw) and disabling some of the warnings (some of them are targeted specifically at libraries for instance) you don't care about is enough.

[@NilsElHimoud]

Sonar is a tool. You have to adapt the tool to your needs not the other way round.

[@Rick104547]

​@@NilsElHimoudtrue but you would be surprised by what's already in the full set of build in .NET analyzers. Not that much value in adding sonar to that tbh.

[@marcotroster8247]

@@Rick104547 Yeah right. The dotnet build warnings aren't too bad. If the code compiles and passes the unit tests, it cannot be too bad. You gotta trust your engineers at some point.

[@johnlehew8192]

So basically microservices are too small. That only took 10 years to figure out. Personally I would call it macroservices. Some are calling it modules which is so original. Vertical Slice is another way to describe managing dependencies but wouldn’t this be a distributed monolith? Personally I’m looking forward to quadroliths to become the next big thing. That’s where you break up a monolith into 4 pieces lol. Regardless of how dependencies are managed, and call trees grow, the underlying data is connected across services or slices. The ultimate question is should these dependencies live in the DB, the API, the slice, in graphql, or in the microservice? Now with SSDs, databases scale much better than they did 15 years ago and I predict we will move back to sql because that is the easiest technology and least amount of work to handle dependencies and it scales like never before. At large companies where the system is the company, NoSql is a good fit primarily because it allows the schema to gradually change across the org. Now that I think about it, we should add sharding to vertical slices and create grid computing lol

[@z-a3594]

Please get to the point faster. Took 20 minutes to get to the topic of the talk.

[@joeedh]

Another grifter. Yeesh 37:39 is particularly bad. Seriously, does this conference have no peer review of talks at all?

[@MickaParis]

I agree with you

[@rupture007]

I liked the part where he said the feature was good, but the implementation wasn't quite right. Then proceeded to say "We were changing 80% of the current implementation anyway"

[@rupture007]

And later with BillingProcessor, "don't create a billing service" just change the word to processor and it's somehow different now and people won't make it a dumping ground for Billing related code? There is a lot of things I like in the talk though. I do like keeping feature related code together. I'd like to see some "real" world example of this style of application and not a "Todo" application.

[@lilivier]

​​​@@rupture007 What he meant is to not have a generic service class that contains dozens of methods doing different things, but have a class with a single method that just does one thing (Single Responsibility Principle). This is the idea. The fact that he choose to name it BillingProceseor is indeed not great. It should have been something like 'BillingInvoiceSender'. But this is not what really matters here. What matters here is to apply SRP.

[@ianhamilton8376]

Depressing. Coders focus on the job of the day, while managers focus on the bigger picture, including requirements. This is clearly someone making a transition and struggling with it. Vertical slice architecture? Well, that has been around in the forms of both the modular monolith and domain based services for over 20 years. Other architectures are available. He really has only described the principles of the modular monolith/client, which really have been around for over 20 years now, but somehow he seems to think this is something new. What this really shows is how poorly software architecture is understood by so many developers.

[@vincentcifello4435]

Please define what you mean by “service” , Chris. Frankly, I don’t think you have a definition. If you have have a slice that “has everything the screen needs to display”, then you do not have a vertical slice. By definition, “the screen” is a composition of data that may come from non-cohesive sources. That coupling will flow backwards from the screen to the components in your “slice” to the database. This is not avoidable when you conflate the user mental model (the screen) with a vertical slice.

[@Rick104547]

I think it's totally fine to have a optimized projection for a certain screen that takes its data from multiple sources. That also allows you to optimize the performance of that slice for that use case. Think of a page that displays aggregated data from multiple sources. Much easier to do that with a dedicated endpoint vs separate generic endpoints.

[@annoorange123]

He bashes services, yet shows monolith classes lol.. service is not supposed to be big. And splitting by feature is done in react projects for like a decade, i thought this is old news