3 ms·
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
by 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 agoInteresting 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 agoif 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