5 ms·

> Organize your files around product features / pages / components, not Roles: Oh really? Can someone explain why is this a good thing and what's the benefit?

> Organize your files around product features / pages / components, not Roles: Oh really? Can someone explain why is this a good thing and what's the benefit? [1] : https://github.com/wearehive/project-guidelines#6-structure-and-naming- https://github.com/wearehive/project-guidelines#6-structure-...

gumoro 9y ago
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.javapractices.com/topic/TopicAction.do?Id=205 http://www.codingthearchitecture.com/2015/03/08/package_by_component_and_architecturally_aligned_testing.html http://www.codingthearchitecture.com/2015/03/08/package_by_c...
Softcadbury 9y ago
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.
- rsj_hn 9y ago
  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.
lhnz 9y ago
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 https://github.com/erikras/ducks-modular-redux
- jrimbault 9y ago
  Unix tools in general fit this approach ? Do only one thing and do it well, offer an interface to other tools and users.
underwater 9y ago
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.
- Illniyar 9y ago
  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.
- nickthemagicman 9y ago
  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.
andreasklinger 9y ago
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`
- whatnotests 9y ago
  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?
  - andreasklinger 9y ago
    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
saltedmd5 9y ago
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.
Illniyar 9y ago
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)
- maaaats 9y ago
  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.

gumoro 9y ago

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.javapractices.com/topic/TopicAction.do?Id=205 http://www.codingthearchitecture.com/2015/03/08/package_by_component_and_architecturally_aligned_testing.html http://www.codingthearchitecture.com/2015/03/08/package_by_c...

Softcadbury 9y ago

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.

rsj_hn 9y ago
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.

lhnz 9y ago

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 https://github.com/erikras/ducks-modular-redux

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

underwater 9y ago

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.

Illniyar 9y ago
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.
nickthemagicman 9y ago
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.

andreasklinger 9y ago

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`

whatnotests 9y ago
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?
- andreasklinger 9y ago
  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

saltedmd5 9y ago

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.

Illniyar 9y ago

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)

maaaats 9y ago
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.