Restrictions on the dependency graph

[wildmaples]

To enforce a certain architecture, we need to place restrictions on the dependency graph. Two examples of such restrictions.

1. Package X does not want to be depended on by Package Y
   For example: the inventory team does not want the storefront package to depend on them.
   Layered architecture (Persistence doesn't want to be depended on by Presentation)

2. Acyclic dependency graph
   This check is already included in packwerk, as we believe it's a critical component of architectural success.

We should investigate how we can express this in Packwerk, either via custom checkers, package configuration, or both.

To do

• Change keys in packages.yml to depends_on: or does_not_depend_on: (or something else?) to make it clearer
• Investigate ArchRuby, a gem that runs a static check on an application and determines if it is following a pre-determined architecture.

[alexevanczuk]

Hi @wildmaples ! Going to close this for now since we've merged extensible checkers which will be shipped in Packwerk 3.x! One of the first checkers we'll be adding is a visibility checker (which we already have an implementation for in Gusto), and we've been thinking about layered architecture too!