you want to slice your abstractions by domain logic boundaries

essentially by "what it does, not by how it does it"

eg let's say you want to do notifications for your site.

you want to have everything related to notifications within one folder and have the outside connect to it via one api (eg component)

in backends this would enable you to easily scale in performance (eg move to microservice or separately hosted instance) or team size (isolation in code, less awareness of the overall codebase "needed")

imo the next big web framework after rails will have this setup as a default

    `app/services` instead of 
    `app/controllers, app/models, app/decorators, app/workers, app/assets, app/views, etc`

Interesting point.

    app/services/signup
    app/services/signin
    app/services/newsletter_subscribe
    app/services/create_report
    ...etc

In larger Rails projects I've been on, we often start with a monolith but then break it into different services to scale out.

Starting with different services at the beginning may cause some other problems: what if the boundaries between services was wrong?

if the abstraction was wrong you have the same issues. no matter if you colocate files or not. most likely it is just less of a mess

Higher cohesion and modularity.

I'm glad to see this in an article for JavaScript projects. Here are a few articles for Java projects, that go in more details (I think the concepts still mostly apply to JavaScript projects):

http://www.javapractices.com/topic/TopicAction.do?Id=205

http://www.codingthearchitecture.com/2015/03/08/package_by_c...

It helps the case in which you want every feature/section of your application to be a smaller self-contained application which can be modularised and loaded into other applications and environments.

I think this is the first time I saw the approach: https://github.com/erikras/ducks-modular-redux

Unix tools in general fit this approach ? Do only one thing and do it well, offer an interface to other tools and users.

creating or updating a component is usually cross-concern, so if you want to change some functionality in a component you'll have to update it's controller,view,model etc...

If they are in the same folder, it makes moving between the relevant files for a feature easier (especially if you have a lot of components and finding the right file in your "controllers" folder means searching through a few dozen files).

It also makes reasoning about a certain feature easier - since all the relevant files are grouped next to eachother you can easily move between a feature's controller and it's view.

It also makes moving a feature easier- instead of renaming each file separately you can simply move the folder to anywhere else in the structure (for instance if you move a feature from a specific page to something more generic/shared)

We always try to think that one folder ideally should be able to be copied to its own project and live on as its own npm module.

I'm not so sure that's a good idea. A component is one possible interface to the business logic, but there isn't necessarily a 1:1 mapping.

Colocating data logic together makes it easier to build a data model that is logical and consistent, rather than one that is coupled to UI decisions.

It's not a black and white thing, you can have a feature structure for your UI and services, and one folder with just the data models.

Sometimes your frameworks kinda force it on you too.

Wow. Came here to make this comment. It seems like the whole point of a model layer is to decouple it from the UI and the Controllers.

In addition to notes in other comments, vertical slicing helps to avoid a tendency for rigid layers to emerge (think the rigid and doomed-to-be-messy Controller -> Service -> Repository "pattern"), which ultimately helps lead to looser, more naturally composed component structures.

You can still have files and folders that cut horizontally across those modules (e.g. for things like logging, sending an email, etc. etc.) - in fact, organizing your hierarchy in vertical slices helps to _promote_ good isolation of those cross-cutting concerns.

I think this kind of structure is really useful for frameworks based on components (like React), you can just copy/paste the content of these folders in other projects and it will work.

Yes, when your project is just a single functional layer -- e.g react -- you can then subdivide your code along feature lines. But the entire codebase will include server side code, DB code, and lots of other code that cuts across functional areas and for which you are going to have a hard time organizing it according to features.

Do you put bits of the DB schema definition files/SQL code in there as well? Back end server code? What if it's a completely different team working on that code? What happens when you decide you want a permissions engine or data access layer and need to couple your UI logic to those layers? When you add a replication engine to synch state across different instances, or a dedicated code handling session management, etc.

Over time, the code is going to reflect team structure and functional roles rather than features, and you can really organize by features only when there is one functional area -- e.g. a react app.