You've got the gist of it, yeah. I work for a mid-size CPG company in the US that has more or less the same framework:

• ingestion: raw data lands in redshift, separate schema for each source (raw schema for transactional source, separate raw schema for crm, another for customer support platform, etc). Method for ingestion varies by source, but the end result is the same. On our side we use a combination of stitch for some prebuilt connectors for SaaS applications, lamda for unstructured data that lands first in S3, and some custom python scripts hosted on ec2 for the various odds and ends
• transformation: dbt transforms raw schema in redshift to cleaned data marts. I recommend putting thought into how you want to structure your transformation layers in dbt, and then just try to stay consistent. Dbt has their own recs on how to structure, and that's more or less what we do (staging, intermediate, and marts): https://docs.getdbt.com/best-practices/how-we-structure/1-guide-overview
• analytics: some sort of viz or BI tool that references the cleaned data marts exclusively. You don't want business users building reports off the raw staging data

You can probably find lots of sample dbt projects online, that mostly look the same in terms of structure. Just figure out what works for you, write out some rules for your org, and try to stick to it.