## Metadata - Author: [[getdbt.com]] - Full Title:: Deciding How to Structure Your DBT Mesh - Category:: #🗞️Articles - URL:: https://docs.getdbt.com/guides/best-practices/how-we-mesh/mesh-2-structures - Read date:: [[2023-10-21]] ## Highlights I would have love to see more on how to split > The first (and perhaps most difficult!) decision when migrating to a multi-project architecture is deciding where to draw the line in your DAG to define the interfaces between your projects. Let's explore some language for discussing the design of these patterns. ([View Highlight](https://read.readwise.io/read/01hd8e7srfmhz6e52n6c9520a4)) > Vertical splits separate out layers of transformation in DAG order ([View Highlight](https://read.readwise.io/read/01hd8e7zmwamsd67tccmhfx2ed)) > Horizontal splits separate your DAG based on source or domain. These splits are often based around the shape and size of the data and how it's used. ([View Highlight](https://read.readwise.io/read/01hd8e85cr7q1sr72dz13bb2jx)) > • **These are not either/or techniques**. You should consider both types of splits, and combine them in any way that makes sense for your organization. ([View Highlight](https://read.readwise.io/read/01hd8e8b0zp79mqwtvs17y04s9)) > **Pick one type of split and focus on that first**. If you have a hub-and-spoke team topology for example, handle breaking out the central platform project before you split the remainder into domains. Then if you need to break those domains up horizontally you can focus on that after the fact. ([View Highlight](https://read.readwise.io/read/01hd8e97drd0e7qcmw896qsdm3)) ^50c71e > • **DRY applies to underlying data, not just code.** Regardless of your strategy, you should not be sourcing the same rows and columns into multiple nodes. When working within a mesh pattern it becomes increasingly important that we don't duplicate logic or data. ([View Highlight](https://read.readwise.io/read/01hd8e9nhbhzzc9s5c39efx2ab))