the 2nd part of the article about why you shouldn't write Airflow DAGs, about a framework can help you solve some of the problems related to DAG writing. https://towardsdatascience.com/data-engineers-shouldnt-write-airflow-dags-part-2-8dee642493fb

This is a neat one for context. It reminded me of an idea I had also to expose the dbt dag within airflow somehow, so that huge trees of data backloads/reloads followed by cleanup dbt pipelines could be more easily rerun and troubleshooting done when they broke partway through. Long chains of dependent ETL were not uncommon in my prior jobs. Sometimes we would backload data in one spot and then have to manually pick all the dependent data migration and transformation jobs that should be rerun after it, which seems like a crazy thing when dags already exist. dbt is just another step in that process, and there’s no guarantee that it’s the last step either. It’d be ideal to have a dag view of the whole thing rather than just parts.

+1 “it’d be ideal to have a dag view of the whole thing”