Let me tell you a story
A company I was hired for as a Senior Developer was in what most would consider a crisis or at a crossroad. In t...
For further actions, you may consider blocking this person and/or reporting abuse
100% agree with this. I've been using feature folders (and MediatR) to build everything as vertical slices for a few years now and couldn't go back!
I really wish Microsoft and Co would change their new project templates to help developers fall into the pit of success.
Thanks for feedback Jon!
I'm on board with you. I know Angular tries somewhat to do this... Would be nice to have the backend frameworks try? lol
Absolutely agree! Group by feature not layer (or technology)! This is perhaps the biggest and most impactful lesson I've learned in my programming career.
I think one of the reasons more teams don't adopt this is partly because it can be challenging to do without higher level tools that help you visualize your modules and their dependencies. It's a lot easier to throw things together by their file extension than by their conceptual cohesiveness, especially if you have no way to visualize and reason about cohesiveness. I don't think I would be able to do it at scale without Structure101 or similar tool.
I think the biggest problem is that devs are disconnected from the business. Devs are too focused on the technical problems they are solving instead of focusing on the business problems they are solving.
If that was the focus, then organizing your code around the business's products or features just naturally flows out of that.
I think the hard part is that it's such a (poor) standard in the industry to just build all these layers (which are horizontal instead of verticle).
I agree - these types of higher level concepts or "tools" (whatever you want to call it) have been the #1 thing that has made me stand out and get to where I am in my career.
I also don't feel like I'm running around in the dark as much!
These ideas make so much sense but I also feel a bit of sadness because I know my old ways and ideas have to die :)
Do you think new strategies like this are only just now becoming available because of Moore's law?
Hahaha!
If I did have to guess, I think this one, in particular, has to do with the tendency for software developers to get too engrossed in the technologies / technical specifics of what they are doing rather than trying to understand how the business works.
Most devs after-all, I suspect, really have no interest in the business itself, but just want to "build stuff".
That is such a fresh way of thinking about it. I think you've just reshaped my head. What a useful way of thinking about the next codebase I'm looking at.
Awesome! Def. let me know how things go when you get a chance to do this kinda stuff 👍
This point cannot be understated. when working with horizontal layer, poor design choices affect the entire codebase, and it's difficult to fix (or even understand) the problem. But if a feature slice chooses a poor implementation, well just cut your losses and don't do it again on the next feature. The rest of your app is safely isolated from the design patterns in other features, and you have the freedom to try new things with little risk overall.
Def. agree - having done this on anonymous the team mentioned in the article it's such a breathe of fresh air that new features can introduce new concepts or not use concepts that have been found to be non-beneficial.
So for teams who want to experiment with different ways to structure code etc. it's a fantastic way to do that.
In my case, I'm slowly introducing new concepts like CQRS, Domain Driven Design, etc. to the team - inch-by-inch as new features are built. Works great!
Wow! I've actually implemented a similar structure to a few of my side-projects and definitely it made it easier for me to decide where to new features or find where certain code was. I had no idea it was actually that helpful 😅 Totally agree with this!
This actually feels really similar to the types of design shifts made by React.
First, with JSX, code was split by feature rather than language. (Instead of dividing code into content, styles, and functionality, it's divided by feature -- by component.)
A similar type of shift has been made by the introduction of hooks. Instead of dividing a component's code by lifecycle methods, it is divided by the functionality it supports.
Both changes were controversial at first, but have grown to seem like an obvious best solution over time (more of that yet to come for hooks, I'm sure). Hopefully in the coming years we can learn to better identify and correct backwards (perpendicular?) code separation...
That Coravel Pro piece of kit looks great! We have a similar in-house tool that allows us to do that stuff but in PHP, and it really helps :D
Nice! It's good to get some feedback around that.
Are there any specific abilities of the product you have that you find the most important/helpful?
Most usefull thing is probably the scheduler. Allowing people to simple click 'add scheduled task', and letting them enter command name, options and a schedule.
Also the fact that when scheduled jobs fail, you can see the exact console output of that command when it ran
Cool - ya that's a very helpful utility, instead of relying on manually setting up a cron entry for one schedule etc.- or even code based scheduling which does require a re-deploy for compiled languages.
at work we have different directories for "app/modules/" (e.g.: shop/cart, bill/, ...) and something that we call "framework/modules/*" (e.g.: system/authentication, ...)
I highly recommend this kind of slicing! Thats what i always do before i get into code, figuring out what my app will do rather than how it is done. Everything else are details. Very good advice! 👌😊
In what ways does this differ from the microservices pattern?
Microservices are when individual "features" or "areas" of your product are independently deployable to their own process/run-time - usually done using containers or VMs.
Breaking your code-base into vertical slices by feature is a necessary pre-cursor to scaling out microservices. But you can do this in a monolith (as described in the article) and gain the benefits mentioned in the article.
If you read the final section of the article "Other Benefits" I briefly discuss this idea.
Thanks for the feedback!
Sometimes you never know - better to be a clear as possible 😂