
Sass architecture of your project
There are different approaches for organizing sass architecture, whatever you choose, the main thing is that it be.
I regard the organization of sass as a tool, first of all, it should not interfere and slow down the train of thought. Therefore, starting a project, I don’t know what architecture will turn out, it settles down in the course of work and takes a form suitable for the requirements of the project.
Bem, Smacss, Oocss, Organic-css should give you the flexibility of thought to build your project.
I always start a project with a standard file organization for myself:

All I know is 100% that the core folder will come in handy for me, where the project settings, general rules, helpers will go, let's go through the basic ones:
core / _core.sass

It is used to connect all files from the core folder, you can connect compass here if it is used on the project.
core / _mixins.sass

I try not to carry a bunch of mixins with me from project to project, this file will be overgrown with them as needed, but by default I use a couple of mixins: em, cp, reset-btn.
core / _reset.sass

Normalize didn’t get accustomed to me, I use reset in my projects to level styles in browsers.
core / _settings.sass

This file collects settings for the entire project: font sizes, colors, maximum width, etc.
core / _base.sass

Serves for general rules on the project, body I make the font-size equal to the given variable, so that in the future it is convenient to calculate em using the mixin of the same name, I used to make this font-size equal to 62.5% so that 1em is 10 pixels.
After that, I try to just make up without paying much attention to architecture, sometimes even in one file. But for the entire time of the project, there are points when the future architecture begins to be drawn and then I put everything on the shelves, as the project requires, without inventing restrictions for myself ahead of time, this gives rise to completely different forms of organization:

For example, the site of my small project did not require a special organization, by the way, the source code can be viewed on githba: github.com/omelniz/block-flute A

single-page site divided into blocks,smgomsk.ru

Public speech is already a larger site and required a more flexible architecture. theps.ru
Larger projects should have stricter rules, although they can also begin their journey. Rules must be supported by someone else, otherwise the project will turn into a pumpkin, perhaps in a couple of months.
This is my personal experience in organizing the sass-architecture of projects, it is interesting for me to think with my head, and not blindly use the available methodologies, although sometimes this is exactly what is needed.
I regard the organization of sass as a tool, first of all, it should not interfere and slow down the train of thought. Therefore, starting a project, I don’t know what architecture will turn out, it settles down in the course of work and takes a form suitable for the requirements of the project.
Bem, Smacss, Oocss, Organic-css should give you the flexibility of thought to build your project.
I always start a project with a standard file organization for myself:

All I know is 100% that the core folder will come in handy for me, where the project settings, general rules, helpers will go, let's go through the basic ones:
core / _core.sass

It is used to connect all files from the core folder, you can connect compass here if it is used on the project.
core / _mixins.sass

I try not to carry a bunch of mixins with me from project to project, this file will be overgrown with them as needed, but by default I use a couple of mixins: em, cp, reset-btn.
core / _reset.sass

Normalize didn’t get accustomed to me, I use reset in my projects to level styles in browsers.
core / _settings.sass

This file collects settings for the entire project: font sizes, colors, maximum width, etc.
core / _base.sass

Serves for general rules on the project, body I make the font-size equal to the given variable, so that in the future it is convenient to calculate em using the mixin of the same name, I used to make this font-size equal to 62.5% so that 1em is 10 pixels.
After that, I try to just make up without paying much attention to architecture, sometimes even in one file. But for the entire time of the project, there are points when the future architecture begins to be drawn and then I put everything on the shelves, as the project requires, without inventing restrictions for myself ahead of time, this gives rise to completely different forms of organization:

For example, the site of my small project did not require a special organization, by the way, the source code can be viewed on githba: github.com/omelniz/block-flute A

single-page site divided into blocks,smgomsk.ru

Public speech is already a larger site and required a more flexible architecture. theps.ru
Larger projects should have stricter rules, although they can also begin their journey. Rules must be supported by someone else, otherwise the project will turn into a pumpkin, perhaps in a couple of months.
This is my personal experience in organizing the sass-architecture of projects, it is interesting for me to think with my head, and not blindly use the available methodologies, although sometimes this is exactly what is needed.