Your proposed structure is sensible โ it is the standard pattern for large-team monorepo setups with Databricks Asset Bundles. Here is a more complete answer to both questions you raised.
1. Shared Python libraries: build a wheel, wire it as a bundle artifact
Package shared_libraries/ as a standard Python wheel (setup.py or pyproject.toml). In each bundle's databricks.yml, declare it as an artifact with a relative path pointing up to the shared directory. Set a build command under the target so DABs builds the wheel during "databricks bundle deploy". It will then install it on cluster automatically via the bundle's library configuration โ no %pip install needed in notebooks.
The key configuration: set "type: whl", "path: ../shared_libraries", and "build: pip install build && python -m build" under the target. DABs resolves the path relative to the bundle's databricks.yml file, so ../shared_libraries correctly reaches the sibling directory at the monorepo root.
2. Shared notebooks: use relative path references, never copy
DABs resolves notebook_path values relative to the databricks.yml that declares the job. For notebooks that live above the bundle root, use "../" traversal: "notebook_path: ../../shared_notebooks/transform_utils". This works for any depth as long as the target path stays within the repository root.
The critical rule: do not copy shared notebooks into each bundle's src/ directory. Copies drift immediately once the shared notebook is updated and you forget to propagate the change.
3. Shared variables: root-level variables.yml with include
Place a variables.yml at the monorepo root with catalog_name, environment prefix, and any other cross-bundle constants. In each bundle's databricks.yml, add an "include: [../variables.yml]" block. Bundle-level variables with the same key override root-level ones, so you get shared defaults with clean per-bundle overrides where needed.
On whether splitting one large bundle into domain bundles is the right call
Yes, for your situation it is. A monorepo with multiple bundles is the right pattern when teams share the same CI pipeline and deployment cadence, shared library code changes infrequently or is versioned via the wheel, and you want cross-bundle dependency visibility in a single repository.
The only reason to split into separate repositories is if business domains have genuinely different release cycles (one team ships 10 times a day, another ships weekly), if repository-level access control is required for compliance, or if the CI pipeline becomes too slow even with path-based change filtering. For most teams under roughly 30 engineers and 5 business domains, the monorepo structure you described handles this cleanly.
