Вот Вам рекомендация от одного из авторов Redux, Дэна Абрамова:
https://react-file-structure.surge.sh/
По делу, так и есть. И Вы абсолютно правы насчёт "в каждой разработке своя организация". Такая же разная организация будет от проекта к проекту.
При всём этом, могу выделить некоторые общие субъективные рекомендации:
- разбивайте приложение на слои, например
— api layer, знает куда сходить за данными и как замапить респонс
— state layer, знает как изменять и хранить состояние приложения, a.k.a actions/reducers
— core layer, знает про api и state, аналог application layer в ddd, в react way могут выступать как saga/thunk/context
— shared/common/utils, всякие вот эти вот тупенькие хеплеры. У меня такое в каждом проекте есть. А кто-то смущается иметь такой слой, мол "как-то не engineer-way". Всё нормально. Вот пара примеров:
react,
create-react-app.
- не злоупотребляйте магическими путями (смесь webpack resolve.modules или alias и "модулей" с index.js) - можно отстрелить ногу циклическими зависимостями. Очень мощная штука, однако без уверенных фундаментальных знаний в архитектурной области можно очень быстро намудрить лапши.
По поводу "посмотреть (простые), на которые равняться" - вот вообще не рекомендую. Я за свою жизнь видел очень много чужого кода, который я внутри себя критиковал, но при этом пытался найти самые "лаконичные" нотки в имплементации. Как результат - видишь очень много всего, как хорошего, так и плохого, что помогает принимать решения в разработке. Желательно закреплять практикой, вроде pet-projects.
Можно увидеть код от "крутого программиста" и пытаться его копировать, но без глубокого понимания решения, скорее всего, получится каша.
https://github.com/gothinkster/react-redux-realwor... - простая реализация клона medium.com, содержит многие типовые операции.
https://github.com/codesandbox/codesandbox-client - исходный код
https://codesandbox.io 
Средний
