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

Thanks for the paradigm shift with regard to code duplication

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?

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.

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 !!!!!!

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.

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.

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.

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

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).

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.

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.

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.

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