Thank you for this video. I've been seeing this type of architecture a lot in my works, but have not known the name for it until now. I think another important aspect in crafting the silo structure is that, in the position of a senior developer or an architecture, the audience of our system is not only the end-users, but also other developers who continue to extend and maintain the system. We may mistake that the audience are only the other developers, but forget about ourselves. If the author of the silo structure takes 5 minutes to figure out what to do to create a new silo (maybe after 2 years assigned to other projects and revisit this one), the junior developers may expect to take 1-2 days. So the point is, if we want a system where junior developers are productive, that productivity must be a few times more for the authors ourselves. Also, I guess we developers are like gamers motivated by sense of achievements. So if we can easily see a small experimental silo that we created working (not through extensive setup and testing), it feels like a mental boost in productivity to complete a full blown silo.
I know this depends on quite a few things, but, for me it has always been difficult to identify what a *feature* really is. sometimes you have something like, calculating the transporting costs of a product, but then you may have some other 'features' added to it which modifies how that transport thing works, so would those smaller developments be features in on themselves, and should they be siloed?
Discussion around coupling can never be underdone; it is almost always the source of the pain in a software system. So, thinking about Silos is a nice way to think about de-coupled design. Some additional thoughts to this pattern would include: 1. Reference Architectures - these designs enable teams to build solutions that work and can be managed within a business. They contain all of the things Derek mentioned: persistence, logging, metrics etc, etc. 2. Golden Paths - these might be templates, scripts or whatever that enable teams to get their solutions built and deployed quickly using a Reference Architecture If you can get there (its not easy), you'll see velocity improve, quality improve, and on-boarding of new developers improve
We have a similar setup. We were able to quickly have new devs working on features in parallel. However, when it came to working on bugs it was difficult for them to understand how all these pieces (or silos) fit together. We're still struggling with that.
From our experience, vertical architecture/silo is much better in (de) coupling, (in) dependencies and testing. Each developer can better isolate their work from the other. The down side : developers should or must be full-stack. The worst point of horizontal/layer architecture is the integration. In some case, integration can take longer than the system development.
I can't stop laughing a these comments including @liquidcode1704 . 😂 In hindsight, yes I can see how it looks like it. Easily one of the best comments I've got ever.
Right before the end of the video he explains that vertical slices is how he likes to implement this concept. But it is also applicable to a layered architecture.
This silo is module, and architecture is call majestic monolith that is very good structured but doesn't solve coupling and introduce complexity. So architect should make mistakes meny times to learn when to use witch arhitektura pattern.😅 Project should have stages to evolve from monolith to majestic monolith then in the end microservices, and when is time to move in next stage that is art...
I'm referring more-so to logical boundaries in more of the sense of a bounded context in Domain Driven Design. It's coupling and cohesion, nothing about physical boundaries of a monolith or microservices of independent deployable units. That's a different concern.
I think the devil is in the details with this topic. It's easy to sketch out an event architecture, but when people go to implement it, they're left scratching their heads on how to actually do it all. What types of processes? What off the shelf libraries? What types of databases? What wire protocols? Envelopes? Etc etc...
Yes, yes for sure. Each situation is going to be different, but the fundamental is coupling and cohesion is really what I'm suggesting to focus on. How you get there are those details.
@@CodeOpinion It would be nice to see examples. I don't think people can always figure it out easily. Even if it's just a reference example, would go a long way.
idk why, but that shirt just kinda looks like a hospital gown lol
😂 this made me chuckle. You're not wrong. I never thought of it.
@@CodeOpinion😊😊
Thank you so much for switching your presentations to dark mode! My eyes are happy.
Ha! No problem. The last few have been dark. I'll try and keep it that way going forward.
Thank you for this video. I've been seeing this type of architecture a lot in my works, but have not known the name for it until now.
I think another important aspect in crafting the silo structure is that, in the position of a senior developer or an architecture, the audience of our system is not only the end-users, but also other developers who continue to extend and maintain the system. We may mistake that the audience are only the other developers, but forget about ourselves. If the author of the silo structure takes 5 minutes to figure out what to do to create a new silo (maybe after 2 years assigned to other projects and revisit this one), the junior developers may expect to take 1-2 days. So the point is, if we want a system where junior developers are productive, that productivity must be a few times more for the authors ourselves.
Also, I guess we developers are like gamers motivated by sense of achievements. So if we can easily see a small experimental silo that we created working (not through extensive setup and testing), it feels like a mental boost in productivity to complete a full blown silo.
Tremendous video, Derek! 👏🏻
In my experience, these principles are seldom discussed.
They are discussed here!
I know this depends on quite a few things, but, for me it has always been difficult to identify what a *feature* really is. sometimes you have something like, calculating the transporting costs of a product, but then you may have some other 'features' added to it which modifies how that transport thing works, so would those smaller developments be features in on themselves, and should they be siloed?
Discussion around coupling can never be underdone; it is almost always the source of the pain in a software system. So, thinking about Silos is a nice way to think about de-coupled design.
Some additional thoughts to this pattern would include:
1. Reference Architectures - these designs enable teams to build solutions that work and can be managed within a business. They contain all of the things Derek mentioned: persistence, logging, metrics etc, etc.
2. Golden Paths - these might be templates, scripts or whatever that enable teams to get their solutions built and deployed quickly using a Reference Architecture
If you can get there (its not easy), you'll see velocity improve, quality improve, and on-boarding of new developers improve
I wish more of my co workers watched your videos. My companies architects seem obsessed with layers of indirection
Indirection isn't bad and shouldn't be avoided or used for no reason. It has a cost.
@@CodeOpinion Which is true of all things. One day my organization will discover a balance.
We have a similar setup. We were able to quickly have new devs working on features in parallel. However, when it came to working on bugs it was difficult for them to understand how all these pieces (or silos) fit together. We're still struggling with that.
There can be some coupling between pieces but it should generally be manageable. If it's not then they could be more coupled than you think?
@@CodeOpinion could be. We’re working on improving our telemetry and telling our devs to find the related traces when looking into the issue.
Excellent topic and useful information.
Thanks, Derek.
Glad it was helpful!
From our experience, vertical architecture/silo is much better in (de) coupling, (in) dependencies and testing. Each developer can better isolate their work from the other. The down side : developers should or must be full-stack.
The worst point of horizontal/layer architecture is the integration. In some case, integration can take longer than the system development.
Thanks for this :))
My pleasure!
What do you mean by silo? Like separate project? Separate folders?
I can't stop looking at your T-shirt as a sleep-ware.
Feels like you are almost going to bed, haha
I was thinking hospital gown!! lmao
I can't stop laughing a these comments including @liquidcode1704 . 😂 In hindsight, yes I can see how it looks like it. Easily one of the best comments I've got ever.
Great video thank you.
using CQRS pattern is key. lots of boiler plate with 100s of files but they easy to test and only does one thing
Having reads and writes be different paths is simplistic but has a lot of implications.
Sounds a lot like your description of Vertical Slice
Right before the end of the video he explains that vertical slices is how he likes to implement this concept. But it is also applicable to a layered architecture.
This silo is module, and architecture is call majestic monolith that is very good structured but doesn't solve coupling and introduce complexity. So architect should make mistakes meny times to learn when to use witch arhitektura pattern.😅 Project should have stages to evolve from monolith to majestic monolith then in the end microservices, and when is time to move in next stage that is art...
I'm referring more-so to logical boundaries in more of the sense of a bounded context in Domain Driven Design. It's coupling and cohesion, nothing about physical boundaries of a monolith or microservices of independent deployable units. That's a different concern.
As always excellent presentation
Thanks again!
Please explain this logic with sample code and projects. Thanks :)
Easier said then done building a reference app
@@CodeOpinion thanks for acknowledge and reply
I think the devil is in the details with this topic. It's easy to sketch out an event architecture, but when people go to implement it, they're left scratching their heads on how to actually do it all. What types of processes? What off the shelf libraries? What types of databases? What wire protocols? Envelopes? Etc etc...
Yes, yes for sure. Each situation is going to be different, but the fundamental is coupling and cohesion is really what I'm suggesting to focus on. How you get there are those details.
@@CodeOpinion It would be nice to see examples. I don't think people can always figure it out easily. Even if it's just a reference example, would go a long way.
EDA doesn't remove coupling. It just makes it harder to track.
It adds more moving parts, but "harder to track" isn't true in my experience.