# How to arrange code folders with dependencies

> Do not try to represent `graph` using `tree`. It's impossible

## Upper-Bottom Layers v.s. Child-Parent relationship

When you have conceptually related components with dependencies like this at the beginning

digraph D {

  A -> B 
  A -> C
  A -> D

}

Please do NOT put them into folders in this way

/A
-/B
-/C
-/D

Why? Becuase one day it might suddenly become

digraph D {

  A -> B 
  A -> C
  A -> D
  
  A2->D

}

Now A and A2 shares D but A and A2 has no relationships. How can you arrange you folder?

So the recommended approach is here

/B
/C
/D
/A
/A2

Just give up representing a graph by using a tree. It's not possibile unless you want to duplicate things.

If you have confidence that A and A2 are in the same level, while BCD is the next level. Then you can do

/layer1
-/A
-/A2
/layer2
-/B
-/C
-/D

To represent this:

digraph D {

    subgraph cluster_layer1 {
      A;
      A2;
    }

    subgraph cluster_layer2 {
      B;
      C;
      D;
    }

    A -> B 
    A -> C
    A -> D
    A2->D

}

Now let's do an exercise, We got an F node that will points to A and D and G node that will points to A and C and F. How do you arrange the folder?

digraph D {

    F, G

    subgraph cluster_layer1 {
      A;
      A2;
    }

    subgraph cluster_layer2 {
      B;
      C;
      D;
    }

    A -> B 
    A -> C
    A -> D
    A2->D
    F->A
    F->D
    
    G->A
    G->C

}

Right, we do this

/F
/G
/layer1
-/A
-/A2
/layer2
-/B
-/C
-/D

What happens frequently is that we often misunderstand something as a root and start creating sub folders for it. And suddenly there comes another "root" like A2, and then F and then G.

To be ready for new nodes joining, the recommended approach is that do not think in a parent-child relationship. Instead, think of a "upper layer and bottom layer" relationship, which is more extendable.

## Real life Example simplified

You write a web service like this at the beginning

/server
-/orders/getOrders

Which seem making sense.

Now you want to write a script for some routined maintenence purpose.

/maintenence
-/whateverScripts
/server
-/orders/getOrders

Suddenly! You found that the `server/order/getOrder` function is quite reusable. And you want to reuse that logic in this maintenence task. So the depdendencies is like this

digraph D {
rankdir=BT
      order;
      getOrder;
          server;
          maintenence

    server -> order
    order -> getOrder
    maintenence -> order

}

However, your code in maintenence mostly will be like this

/maintenence
-/whateverScripts(import from ../server/orders/getOrders)
/server
-/orders/getOrders

That's the mistaken part. The second line will bring a misunderstanding on the dependencies, people will misunderstand that the offline maintenence requries the server, like the graph below, which is not true.

digraph D {
    rankdir=BT
      order;
      getOrder;
          server;
          maintenence


    server -> order
    order -> getOrder
    maintenence -> server
    
    label = "wrong relationhips (maintenence does not depend on server)"

}

Do you need to start a server in order to complete the maintenence task? No! You just need the getOrders piece of reusable logic.

Instead, you should arrange the code folders like this

/order
-/getOrders
/maintenence
-/whateverScripts(import from ../orders/getOrders)
/server
-/whatverService(import from ../orders/getOrders)

Now this dependency matches to actual dependencies

digraph D {
      rankdir=BT
      order;
      getOrder;
      
          server;
          maintenence
    
    

    server -> order
    order -> getOrder
    maintenence -> order

}