Designing for change with Vertical Slice Architecture - Chris Sainty - NDC London 2024
This talk was recorded at NDC London in London, England. #ndclondon #ndcconferences #developer #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences.com
ndclondon.com/
Subscribe to our KZhead channel and learn every day:
/ @NDC
Follow our Social Media!
/ ndcconferences
/ ndc_conferences
/ ndc_conferences
#dotnet #architecture #agile #ddd #microservices #software #apps
While traditional layered architectures have held their ground for years-structing applications into recognisable tiers such as “presentation”, “business logic”, and “data”. Are they really suited to the demands of modern software development?
Teams are being asked to move faster and faster as well as be able to change direction quickly as customer needs change. And what happens when a product hits success and needs to scale, fast! Do these architectures make it easy for apps to scale and new developers to get up to speed and be productive quickly?
Essentially, do these architectures allow teams to build for change? The one constant in our industry.
In this talk, we’re going to look at an alternative way to build applications using vertical slice architecture (VSA). You’ll learn what VSA is and how it differs from the layered approach. We’ll cover it’s key advantages and how it can help you, or your teams, build better software, faster. We’ll also talk about some common misconceptions of the architecture as well as trade-offs when choosing it.
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?
Thanks for the paradigm shift with regard to code duplication
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.
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.
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 !!!!!!
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).
But should not this be a separate module then?
Domain events and the corresponding handler seem like a good solution to this problem.
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.
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.
Please get to the point faster. Took 20 minutes to get to the topic of the talk.
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.
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.
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.
Sonar is a tool. You have to adapt the tool to your needs not the other way round.
@@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.
@@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.
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.
just place cross concern stuff (auth, 3rd party junk) in something that is shared, but keep each feature separate
@Ry4nWTF But then it wouldn't be vertical slice architecture :) Seriously this is a 70s level view of software.
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.
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.
@@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.
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.
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.
Another grifter. Yeesh 37:39 is particularly bad. Seriously, does this conference have no peer review of talks at all?
I agree with you