@CodeOpinion it would be great if you did a video about how to keep low coupling and high cohesion once a project reachs the operation phase, once the gurus are not around and a cheaper team takes the ownership. As you said someone could be so great that is able to build a v slide with no coupling in only one project, but later when someone else with less experience has to maintain it will break it easily bc the lack of structure.
I find Functional Core Imperative Shell (FC/IS) to be a great simplification of most architectural designs. It only contains two layers. The core has pure functions only with domain logic, and the shell around it contains everything infrastructure related. I combine it DDD and like a lot for its simplicity.
I almost always use Vertical Slices - in libraries, console apps, web apps - I try to first think about coupling and cohesion which leads to well defined vertical slices. However, I only use Ports&Adapters/Onion/Clean architecture when I need that to help manage domains/boundaries/concepts/complexity. Vertical Slices are just as helpful in "simple" CRUD apps with transaction scripts as they are in more complex/prescribed/formalized architectures.
I don't think managing domain/boundaries is the sole responsibility of CA... You can very well manage any of that while implementing VSA on top of the domain without having to resort to CA exclusively.
@@CesarDemi81 yep, good point. I wasn't trying to say that managing domains or boundaries was only possible with clean architecture (or any of the other names it has). Needing to manage domains and boundaries is often a precursor to CA but definitely doesn't necessitate it (which is what I originally stated in a different way).
Having each vertical slice use different architectures sounds good in the sense that you can have the most optimal architecture for each feature but then you lose consistency across your entire project since now each feature can be organised differently, which I think will make it harder for developers to collaborate. There's obviously a tradeoff but I think being consistent across features is most of the times more valuable than having an optimal architecture per feature, even if you end up with redundant layers.
Exactly what I thought. There's nothing bad about a fixed project structure template as long as you can use it for complex and for simple tasks. The great benefit is that all projects look the same and every developer is familiar with it. It's not realistic that every team starts to think about it's own architecture. This will be a mess soon. And speaking of using mighty frameworks like Spring Boot there's even more the need for standardised bean structures.
If it will turn out that only 20% of the features need so complex desing, you will end up with overcomplicated system- with tons of indirection layers that do nothing - typical for corpo-Java projects.
What we did is try to keep the "internal architecture" consistent per module (we're building a modular monolith) and only deviate if the use-case requires something specific. Some modules are extremely CRUD'y, which means just using transaction scripts is "good enough". Some modules require complex business logic, which means DDD is a better fit. Some use-cases require fetching data a whole bunch of data in real-time (e.g. our reservation system) which means using Dapper over EF Core for query speed optimization for those specific slices. Most don't, which means EF Core is "good enough". ...
Good video, as always; I am frequently impressed with how much mileage you get out of slides with boxes and lines. That's the sign of a good architect! Also, I appreciate that you touched on the elephant in the room with clean architecture, and the project structure; YOU DON'T NEED 4 PROJECTs, haha. The 4 projects are the thing I typically frown upon when someone mentions CA, I look forward to the video.
@@evancombs5159 some .NET technologies make it harder to put UI files where ever you want, which I find annoying. Like they expect files to be in a certain path. In general I like to have everything that is responsible for a specific task close together in code, including UI if possible. In some cases it may either not be possible or just not be practical depending on the roles, responsibilities of people working on the code, or if UI requires separate versioning and deployment strategies.
Ha, I often think the same thing to myself about having videos with boxes and lines. I view all of these as lightning talks really. That's where the presentation style comes from is from doing conference talks.
But it is just easier to enforce that coupling stays a minimum with actual "physical" projects. People tend to have the craziest ideas to hack things and introduce more unnecessary coupling. I think separate projects help with this because they cannot access things they shouldn't. I also don't see how having multiple projects and the abstractions related to them makes anything really any more complex. I agree that if people could actually understand the concepts we might not need these kind of safeguards, but most people are monkeys and have no idea how to create good products.
I use Clean Vertical Slice Combo = Clean Arch for layers + Vertical Slices for concrete features in layers. P. S. Good video, as always. Thanks, Derek.
Thank you. Yep I saw a lot of really small projects, which require nothing more than monlith and vertical slice, but for some weird reason there was clean architecture, tones of services and complex infrastructure. Even though the projects were used by max 50 people daily and had a very simple business logic. Clean architecture became as a religion withing developers. Need it, don't need it - use it everywhere. Better with microservices, kubernetes cluster on AWS, paying for it hundreds of dollars, when for the project 5$ on Digital Ocean will be more than enough.
Very well explained! I ALWAYS split my solution vertically into modules (one module = one vertical slice or one functionality). I have a folder "Modules" in my solution when I put all my code to. Nowhere else. It can either be a Modules folder in a solution with each module being one project, or it can be a Modules folder in a project having modules in sub-folders simply as files. In Modules folder, when it grows larger, I tend to split it into sub-folders to group modules together using things that these modules have in common. When one opens the solution can quickly see what functionalities is application made of.
Hi Derek, I remember the last time I looked there was a section on slices (screaming architecture) in the Clean Architecture book. I'm curious, why the insistence on dividing the project into layers? Couldn't we just label components by their layer names and set up the linter to enforce the dependency rule? Just a thought.
In the .NET world, people love them some projects. They are about reusability but seemingly it's been used as a way of enforcing the separation because you can't cause a circular reference. But ya as mentioned you could enforce it in other ways.
In smaller projects it doesn't matter. In bigger ones, with many team members, it's easier if you obviously separate modules. Plus you can tdd/unit test them without the glue code that runs the app.
@pyce. not at all. CA is based on Dependency Rule, which is great. It's just a matter of scope. If you build monolith with 2-3 teams and base it on CA only, you will end up with big ball of mud. Whereas CA in a single module is advisable.
Even with vertical slicing you're going to have shared stuff like logging, authentication etc. Those don't belong in any one slice so putting them in 'shared' (or whatever your naming/structure is is fine. Libraries you use might fall into this category but you might also write code yourself that falls into this. How exactly you implement it really depends on your situation though. I find that vertical slicing with 'clean architecture' (mostly focusing on the direction of types, not so much the layers) between types is flexible, pragmatic and easy to understand for any developer and thus makes them productive.
How thin is a slice? For example, in a workout app, it will typically contain entities such as users, exercises, and routines. Would a slice be considered a routine along with every action associated with it, or would a slice represent an individual action? For instance, when implementing CRUD operations for a routine, would each CRUD method constitute its own slice, or would the entire routine be considered a single slice? If the slice is the entire routine, i dont see how different it is from DDD.
A slice can be an individual action if that individual action has value on its own. Some slices are a combination of actions because they don't have value on their own. There's usually a set of core features that most thinner slices require. As an example, let's say you have a wishlist, the core actions of maintaining your wishlist might exist, but you create a slice that allows you to import a wishlist from another website/source. That importing feature is on it's own and could be deleted without affecting anything else.
So ideally you start designing vertical slices and within those slices you implement clean architecture and/or ports and adapters. It makes a lot of sense
If all CA/Onion is is a thought about how to organize dependencies, does it really deserve the term "architecture"? If it "isn't" about prescriptiveness, then is it really all that profound? Is it just saying "not the active record pattern"?
Great video. The confusion is based in bad naming. Clean, Onion, Hegagonal und Vertical Slice Architectures are not architectures. They only describe a characteristic of a (potential) architecture. As in: my architecture uses vertical slices to structure the parts of the system, some parts use Hexagonal-style to separate logic from drivers through adapters and some parts, in addition, use Onion-style layers to structure different responsibilities for easier comprehension.
Template or no template, truth is that CA explicitly forces you to implement indirection in order to decouple those (physical or logical, it doesn't matter) layers; so you're generally still forced to implement some repo pattern on top of, say, EF Core, because otherwise "you're violating the all mighty dependency rule", and since this rule is the prime directive of CA, if you break it you don't have CA, and if you want to call it CA you need to respect the dependenct rule... In this matter, VSA gives much more freedom and is way more flexible, less ceremonious and allows faster delivery of value. So all in all, I think *this* is where the discussion needs to be centered on when discussing about VSA vs CA or similar; because in the end, we're here to help architecting systems that not only do what the client expects them to do, but also do it in the most efficient and simplest way possible (KISS), without having to resort to overcomplicated stuff "just because it looks cool to throw patterns and the sink too".
Dependency Rule still applies, even in VSA. It wasn't invented with Clear Arch. It's a basic design rule that applies on all levels. It doesn't apply in places that you won't change in future though. E.g. if your feature is manipulating files on the disk, you don't want to mix this with business logic that calculates the data. Or if you do some CosmosDb operations - that's a nasty code - if should not reside with business logic. (Otherwise how would you replace it with an in memory stub in tdd/unit tests)? It doesn't mean though you have to do a big repository that hold ALL operations in one place.
@@seNick7 With VSA you apply abstractions ONLY when needed. In CA you apply abstractions ALWAYS because that's its standard ceremony. That's my point. In VSA you can work with DbContext, which already provides repository pattern with the DbSet (Set) and unit of work (SaveChanges); while in CA (and this is very common in *every* implementation I've seen around), you ALWAYS implement Repository and Unit of Work even on top of DbContext. Are you going to frequently switch ORM app-wide? It's most likely to switch DB than ORM, and that's what the ORM is for: to abstract (up to a point) the DB implementation. So what do you gain by abstracting something already abstracted? Now it's much easier than before to mock a DbSet in EF Core, so there isn't a real need for "I need to abstract it because I can't mock it for tests". I did it in several projects, it's not hard. And it's WAY easier to perform an Include().ThenInclude() or different kinds of filtering and sorting directly from a handler instead of having to work your way around a repository interface, create a lot of parameters to be able to pass these things around, etc. You need to work with Dapper? Ok, that's a fair case for applying Repository and UoW... You can do it in VSA just as in CA. Also, in VSA I can have all in the same Application "layer", and I wouldn't require to have indirections other than the strictly necessary to test, while in CA you even see implementations of "UserContext" to be able to inject a ClaimsPrincipal, which is not even part of oif ASP.NET Core, but CA archs always want to overcomplicate things and create extra services and indirections, huge ceremonies to implement even the most basic stuff. In the meantime, the devs all the time asking "what layer should this go?" repeatedly. Because it's unnecessarily complicated for most of them to understand all the ceremony CA normally forces you into. I hope I made myself clearer. Thing is not about the necessity of abstracting: if you have some file handling stuff, you create a service class that acts as a facade of that functionality to inject it and use it from the handlers, but that's a different thing against all the other stuff I explained above and that makes life harder in every single CA project I've seen around. Cheers.
In some ways, yes, as they are both about defining boundaries around capabilities (functional cohesion). There's also an aspect about physical deployment that modular monoliths involve. However, modular monolith is more about breaking apart (boundaries) by subdomains and vertical slices are more within that subdomain or workflows across them.
No. Modular monoliths are about uniting the subdomains into a monolith (instead of multiple containerized services), whereas vertical slice architecture is about the structure within a subdomain. They can both coexist.
So what is the right way of combing them? I say, that is where there is no absolute answer if you are looking for the perfect solution. I tend to put stuff in one project. But some architects say they don't trust other devs to enforce the separation logically, and they think having this strict structure gives them that benefit of controlling those qualities. And sure, in some places devs are oblivious to the architecture, but it is quite condescending to wanting to limit them when this is something they can learn.
Thinking about those diagrams, arrange those vertical slices radially on the Clean diagram. But in terms of implementation, it's common that the UI is in a different language from the backend, so it's natural to put the UI modules together, even while you think about the stack of UI to presentation model to business rules to model backend. Now if we're keeping our model clean, that vertical slice may go into the core of the diagram and back out again, to avoid logic depending on a particular database. So when I'm working, small team, I work on a vertical slice, but the pieces of that slice are not kept together.
There's no better teacher than a compile error. Strict enforcement of principles is what guides juniors to do the right thing early on. I don't buy the condescension argument, it's really something you as a developer need to get over. Writing code is not about any one individual. It's about the team who was to maintain it and the users who have to use it. Discussing approaches should always be welcomed, but going on a separate tangent makes the code base inconsistent at best and unintelligible at worst. The "best" approach is always dependent on what you're trying to do. Discuss with the team the tradeoffs of each approach. There is never a silver bullet.
Clean architecture is great for webapps as long as you’re not doing it dogmatically. It really helps you structure your thoughts when modelling a solution to a problem; helping you avoid coupling issues and bad abstractions. It’s useless in other problem domains though, such as game development, data science, embedded, etc.
Want to learn more about software architecture and design? Join thousands of developers getting weekly updates!
🚀mailchi.mp/63c7a0b3ff38/codeopinion
@CodeOpinion it would be great if you did a video about how to keep low coupling and high cohesion once a project reachs the operation phase, once the gurus are not around and a cheaper team takes the ownership. As you said someone could be so great that is able to build a v slide with no coupling in only one project, but later when someone else with less experience has to maintain it will break it easily bc the lack of structure.
I find Functional Core Imperative Shell (FC/IS) to be a great simplification of most architectural designs. It only contains two layers. The core has pure functions only with domain logic, and the shell around it contains everything infrastructure related. I combine it DDD and like a lot for its simplicity.
I almost always use Vertical Slices - in libraries, console apps, web apps - I try to first think about coupling and cohesion which leads to well defined vertical slices. However, I only use Ports&Adapters/Onion/Clean architecture when I need that to help manage domains/boundaries/concepts/complexity. Vertical Slices are just as helpful in "simple" CRUD apps with transaction scripts as they are in more complex/prescribed/formalized architectures.
Agree. How you handle separating technical concerns within a slice varies depending on needs and complexity of the domain.
I don't think managing domain/boundaries is the sole responsibility of CA... You can very well manage any of that while implementing VSA on top of the domain without having to resort to CA exclusively.
@@CesarDemi81 yep, good point. I wasn't trying to say that managing domains or boundaries was only possible with clean architecture (or any of the other names it has).
Needing to manage domains and boundaries is often a precursor to CA but definitely doesn't necessitate it (which is what I originally stated in a different way).
Having each vertical slice use different architectures sounds good in the sense that you can have the most optimal architecture for each feature but then you lose consistency across your entire project since now each feature can be organised differently, which I think will make it harder for developers to collaborate. There's obviously a tradeoff but I think being consistent across features is most of the times more valuable than having an optimal architecture per feature, even if you end up with redundant layers.
Exactly what I thought. There's nothing bad about a fixed project structure template as long as you can use it for complex and for simple tasks. The great benefit is that all projects look the same and every developer is familiar with it. It's not realistic that every team starts to think about it's own architecture. This will be a mess soon. And speaking of using mighty frameworks like Spring Boot there's even more the need for standardised bean structures.
I agree, consistency in code is very important, there needs to be a very good reason to add an inconsistency.
Why? Do you have to be consistent across apps too? Lol
If it will turn out that only 20% of the features need so complex desing, you will end up with overcomplicated system- with tons of indirection layers that do nothing - typical for corpo-Java projects.
What we did is try to keep the "internal architecture" consistent per module (we're building a modular monolith) and only deviate if the use-case requires something specific.
Some modules are extremely CRUD'y, which means just using transaction scripts is "good enough".
Some modules require complex business logic, which means DDD is a better fit.
Some use-cases require fetching data a whole bunch of data in real-time (e.g. our reservation system) which means using Dapper over EF Core for query speed optimization for those specific slices. Most don't, which means EF Core is "good enough".
...
Good video, as always; I am frequently impressed with how much mileage you get out of slides with boxes and lines. That's the sign of a good architect! Also, I appreciate that you touched on the elephant in the room with clean architecture, and the project structure; YOU DON'T NEED 4 PROJECTs, haha. The 4 projects are the thing I typically frown upon when someone mentions CA, I look forward to the video.
Something I struggle with is if the UI layer should be a separate project or not. That is the only reason I can see for needing multiple projects.
@@evancombs5159 some .NET technologies make it harder to put UI files where ever you want, which I find annoying. Like they expect files to be in a certain path. In general I like to have everything that is responsible for a specific task close together in code, including UI if possible. In some cases it may either not be possible or just not be practical depending on the roles, responsibilities of people working on the code, or if UI requires separate versioning and deployment strategies.
Ha, I often think the same thing to myself about having videos with boxes and lines. I view all of these as lightning talks really. That's where the presentation style comes from is from doing conference talks.
@@CodeOpinion I feel like the slides are effective at communicating the information clearly.
But it is just easier to enforce that coupling stays a minimum with actual "physical" projects. People tend to have the craziest ideas to hack things and introduce more unnecessary coupling. I think separate projects help with this because they cannot access things they shouldn't.
I also don't see how having multiple projects and the abstractions related to them makes anything really any more complex.
I agree that if people could actually understand the concepts we might not need these kind of safeguards, but most people are monkeys and have no idea how to create good products.
I use Clean Vertical Slice Combo = Clean Arch for layers + Vertical Slices for concrete features in layers.
P. S. Good video, as always. Thanks, Derek.
Thank you. Yep I saw a lot of really small projects, which require nothing more than monlith and vertical slice, but for some weird reason there was clean architecture, tones of services and complex infrastructure. Even though the projects were used by max 50 people daily and had a very simple business logic. Clean architecture became as a religion withing developers. Need it, don't need it - use it everywhere. Better with microservices, kubernetes cluster on AWS, paying for it hundreds of dollars, when for the project 5$ on Digital Ocean will be more than enough.
Agree 100%.
Very well explained! I ALWAYS split my solution vertically into modules (one module = one vertical slice or one functionality). I have a folder "Modules" in my solution when I put all my code to. Nowhere else. It can either be a Modules folder in a solution with each module being one project, or it can be a Modules folder in a project having modules in sub-folders simply as files. In Modules folder, when it grows larger, I tend to split it into sub-folders to group modules together using things that these modules have in common. When one opens the solution can quickly see what functionalities is application made of.
How you are coupled between types is what matters! Great way to put it.
haha an 8 minute video to reiterate 'it depends' 😂 Great videos with clear descriptions. Thanks
Hi Derek,
I remember the last time I looked there was a section on slices (screaming architecture) in the Clean Architecture book. I'm curious, why the insistence on dividing the project into layers? Couldn't we just label components by their layer names and set up the linter to enforce the dependency rule? Just a thought.
In the .NET world, people love them some projects. They are about reusability but seemingly it's been used as a way of enforcing the separation because you can't cause a circular reference. But ya as mentioned you could enforce it in other ways.
In smaller projects it doesn't matter. In bigger ones, with many team members, it's easier if you obviously separate modules. Plus you can tdd/unit test them without the glue code that runs the app.
I don't know, can you? I know I can do it with separate projects. Until shown otherwise that is my best option.
It feels to me that "you guys" (sorry I don't have a better phrase for it right now) think that anyone who likes CA must be an ignorant fool.
@pyce. not at all. CA is based on Dependency Rule, which is great. It's just a matter of scope. If you build monolith with 2-3 teams and base it on CA only, you will end up with big ball of mud. Whereas CA in a single module is advisable.
derek, is there any repo available on github to see all the patterns you show on this channel?
No, good suggestion though. I might put something together.
is vertical slice the same as modular monolith?
If not, if slices a feature based, doesn't a "shared folder" break its fundamental purpose?
Even with vertical slicing you're going to have shared stuff like logging, authentication etc. Those don't belong in any one slice so putting them in 'shared' (or whatever your naming/structure is is fine.
Libraries you use might fall into this category but you might also write code yourself that falls into this.
How exactly you implement it really depends on your situation though. I find that vertical slicing with 'clean architecture' (mostly focusing on the direction of types, not so much the layers) between types is flexible, pragmatic and easy to understand for any developer and thus makes them productive.
Finally someone explaining why it makes not much sense to compare Vertical Slices with Clean Architecture. Great video, thanks for sharing!
Hi Derek, would you be able to point out some material covering the vertical slice architecture? Thank you in advance 🙏
Here's a much longer video on the topic. ua-cam.com/video/L2Wnq0ChAIA/v-deo.html
@@CodeOpinion Thank you!
How thin is a slice? For example, in a workout app, it will typically contain entities such as users, exercises, and routines. Would a slice be considered a routine along with every action associated with it, or would a slice represent an individual action? For instance, when implementing CRUD operations for a routine, would each CRUD method constitute its own slice, or would the entire routine be considered a single slice? If the slice is the entire routine, i dont see how different it is from DDD.
A slice can be an individual action if that individual action has value on its own. Some slices are a combination of actions because they don't have value on their own. There's usually a set of core features that most thinner slices require. As an example, let's say you have a wishlist, the core actions of maintaining your wishlist might exist, but you create a slice that allows you to import a wishlist from another website/source. That importing feature is on it's own and could be deleted without affecting anything else.
@@CodeOpinion Very well explained sir
Your videos are simply amazing
So ideally you start designing vertical slices and within those slices you implement clean architecture and/or ports and adapters. It makes a lot of sense
You could. Macro your vertical slice is a service boundary. Micro it's an individual request.
If all CA/Onion is is a thought about how to organize dependencies, does it really deserve the term "architecture"? If it "isn't" about prescriptiveness, then is it really all that profound? Is it just saying "not the active record pattern"?
It's about coupling. It's a way to manage that coupling.
Can we have one class above feature level for endpoints or it will break vertical slice?
Great video.
The confusion is based in bad naming. Clean, Onion, Hegagonal und Vertical Slice Architectures are not architectures. They only describe a characteristic of a (potential) architecture.
As in: my architecture uses vertical slices to structure the parts of the system, some parts use Hexagonal-style to separate logic from drivers through adapters and some parts, in addition, use Onion-style layers to structure different responsibilities for easier comprehension.
Template or no template, truth is that CA explicitly forces you to implement indirection in order to decouple those (physical or logical, it doesn't matter) layers; so you're generally still forced to implement some repo pattern on top of, say, EF Core, because otherwise "you're violating the all mighty dependency rule", and since this rule is the prime directive of CA, if you break it you don't have CA, and if you want to call it CA you need to respect the dependenct rule...
In this matter, VSA gives much more freedom and is way more flexible, less ceremonious and allows faster delivery of value. So all in all, I think *this* is where the discussion needs to be centered on when discussing about VSA vs CA or similar; because in the end, we're here to help architecting systems that not only do what the client expects them to do, but also do it in the most efficient and simplest way possible (KISS), without having to resort to overcomplicated stuff "just because it looks cool to throw patterns and the sink too".
Dependency Rule still applies, even in VSA. It wasn't invented with Clear Arch. It's a basic design rule that applies on all levels. It doesn't apply in places that you won't change in future though.
E.g. if your feature is manipulating files on the disk, you don't want to mix this with business logic that calculates the data. Or if you do some CosmosDb operations - that's a nasty code - if should not reside with business logic. (Otherwise how would you replace it with an in memory stub in tdd/unit tests)? It doesn't mean though you have to do a big repository that hold ALL operations in one place.
@@seNick7 With VSA you apply abstractions ONLY when needed. In CA you apply abstractions ALWAYS because that's its standard ceremony. That's my point. In VSA you can work with DbContext, which already provides repository pattern with the DbSet (Set) and unit of work (SaveChanges); while in CA (and this is very common in *every* implementation I've seen around), you ALWAYS implement Repository and Unit of Work even on top of DbContext. Are you going to frequently switch ORM app-wide? It's most likely to switch DB than ORM, and that's what the ORM is for: to abstract (up to a point) the DB implementation.
So what do you gain by abstracting something already abstracted? Now it's much easier than before to mock a DbSet in EF Core, so there isn't a real need for "I need to abstract it because I can't mock it for tests". I did it in several projects, it's not hard. And it's WAY easier to perform an Include().ThenInclude() or different kinds of filtering and sorting directly from a handler instead of having to work your way around a repository interface, create a lot of parameters to be able to pass these things around, etc.
You need to work with Dapper? Ok, that's a fair case for applying Repository and UoW... You can do it in VSA just as in CA.
Also, in VSA I can have all in the same Application "layer", and I wouldn't require to have indirections other than the strictly necessary to test, while in CA you even see implementations of "UserContext" to be able to inject a ClaimsPrincipal, which is not even part of oif ASP.NET Core, but CA archs always want to overcomplicate things and create extra services and indirections, huge ceremonies to implement even the most basic stuff.
In the meantime, the devs all the time asking "what layer should this go?" repeatedly. Because it's unnecessarily complicated for most of them to understand all the ceremony CA normally forces you into.
I hope I made myself clearer. Thing is not about the necessity of abstracting: if you have some file handling stuff, you create a service class that acts as a facade of that functionality to inject it and use it from the handlers, but that's a different thing against all the other stuff I explained above and that makes life harder in every single CA project I've seen around.
Cheers.
Does Vertical Slicing refer to the same concept as Modular Monolith?
In some ways, yes, as they are both about defining boundaries around capabilities (functional cohesion). There's also an aspect about physical deployment that modular monoliths involve. However, modular monolith is more about breaking apart (boundaries) by subdomains and vertical slices are more within that subdomain or workflows across them.
@@CodeOpinion Thank you for clarifying the difference between these concepts. I believe that would make an excellent title for your upcoming video :)
Thanks a lot for your awesome videos
Do you recommend Vertical Slice for enterprise projects ?
I think it fits best anywhere where you are driven by use-cases.
are vertical slice architecture and modular monolith same ?
No. Modular monoliths are about uniting the subdomains into a monolith (instead of multiple containerized services), whereas vertical slice architecture is about the structure within a subdomain. They can both coexist.
I've never seen anyone misunderstanding vertical slices.
So what is the right way of combing them? I say, that is where there is no absolute answer if you are looking for the perfect solution. I tend to put stuff in one project. But some architects say they don't trust other devs to enforce the separation logically, and they think having this strict structure gives them that benefit of controlling those qualities. And sure, in some places devs are oblivious to the architecture, but it is quite condescending to wanting to limit them when this is something they can learn.
Thinking about those diagrams, arrange those vertical slices radially on the Clean diagram. But in terms of implementation, it's common that the UI is in a different language from the backend, so it's natural to put the UI modules together, even while you think about the stack of UI to presentation model to business rules to model backend. Now if we're keeping our model clean, that vertical slice may go into the core of the diagram and back out again, to avoid logic depending on a particular database.
So when I'm working, small team, I work on a vertical slice, but the pieces of that slice are not kept together.
There's no better teacher than a compile error. Strict enforcement of principles is what guides juniors to do the right thing early on. I don't buy the condescension argument, it's really something you as a developer need to get over. Writing code is not about any one individual. It's about the team who was to maintain it and the users who have to use it. Discussing approaches should always be welcomed, but going on a separate tangent makes the code base inconsistent at best and unintelligible at worst.
The "best" approach is always dependent on what you're trying to do. Discuss with the team the tradeoffs of each approach. There is never a silver bullet.
Please don't smash projects, it's figurative.
Great video Derek, finally a good video about the architecture jargon.
Hot take: if you get to the point where the layout of the files matters, your service is getting too complex and probably doing too much
"This comparison makes no sense". Thanks god!
TBH, I don't get the difficult people have to get it. I know some dudes that just "clean architecture" everything they can, literally
Clean architecture is great for webapps as long as you’re not doing it dogmatically. It really helps you structure your thoughts when modelling a solution to a problem; helping you avoid coupling issues and bad abstractions. It’s useless in other problem domains though, such as game development, data science, embedded, etc.
@@aforslow I like this take "as you’re not doing it dogmatically.", Dogmatism seems to be the root of all evil
Fight fight fight
Vertical is better. Say it.
Onions get out.
🤣