This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Message originally sent by slack user U71V6G2PDJS
Promoted by the thread above: Why do we need layers for Packwerk if we already have a DAG for packs?
One of the benefits I see is establishing a shared mental models of what (different) “roles” packs can have. And making that explicit.
Message originally sent by slack user U70TIGAX94P
I thought I gave a good reason in the thread - granularity. You can start cleaning up the structure of your application in the large, which is
• easier because with less parts (looking at layers, groups of packages, instead of packages) you have less violations between parts
• The highest impact in terms of overall application architecture. You can then actually say that your application has a layered architecture, and devs can think of it and navigate it in terms of those layers.
It lets you reduce the cognitive load devs take on when making changes, because they can ignore large swaths of the codebase; the irrelevant layers.
Message originally sent by slack user U70TIGAX94P
In my blog post, I put it this way:
If determining the desired direction of all the dependencies on a component ever feels overwhelming, we think about the components grouped into layers. This allows us to prioritize and focus on cleaning up dependencies across layers first.
I also give an example. See more at https://shopify.engineering/shopify-monolith