Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: