Seeking Advice on Implementing a "Package Level Guide" to Categorize and Track Progress

System Design
21

Message originally sent by slack user U7213XMGS3H

i can certainly see utility and feature but i’m curious about other ideas

22

Message originally sent by slack user U7213XMGS3H

also do you put all your utility packs in a directory? or is everything flat?

23

moving files into packs is a precondition to be able to start getting metrics about your violations. Then you can start keeping track of those. That’s what my last PR is about, allowing to export stats in CSV https://github.com/rubyatscale/packs/pull/110

24

Message originally sent by slack user U7213XMGS3H

What are some levels you’re using @oboxodo?

25

Not these exactly as I can’t disclose proprietary stuff (lawyers) but something around this. Please note I’m NOT saying these are good layers. Or even well-named. Naming stuff is hard:

architecture_layers:
  - Deprecated  # Stuff we should stop using and eventually delete once nothing else depends on it.
  - Application # Only the main app ".". All "glue-code" goes here. The least, the better.
  - Product     # Two or three main products separated as packs.
  - Feature     # Somme product features which get reused between more than one product.
  - Utility     # Utilities which are not specific about any product or feature. More generic stuff, like rails-shims pack.
26

So… packs you put in “Utility” can depend on other packs in the same layer, but on nothing from layers above. Order is relevant.

27

packs you put in Product can depend on oacks in Feature and Utility, but not on packs in Application or Deprecated

28

and so on

29

Message originally sent by slack user U7213XMGS3H

and feature packs can depend on utility packs

30

Message originally sent by slack user U7213XMGS3H

and you end up having violations… and you work through them

31

Message originally sent by slack user U7213XMGS3H

so if you make a pack layer deprecated, you know the list of things to get rid of, right?

32

IMHO focusing on those violations first is a great goal.

33

Message originally sent by slack user U7213XMGS3H

But how do you say that feature can depend on utility but not the other way around?

34

we have a couple packs we know we want to get rid of. So we moved them from “Feature” to “Deprecated” and that by itself highlights those violations pointing us to where we need to cut wires.

35

But how do you say that feature can depend on utility but not the other way around?

The order you define them in that list is what determines that.

36

the ones at the top can depend on the ones at the bottom

37

Message originally sent by slack user U70TIGAX94P

Strong agree with some of the thoughts expressed in this thread:

• public interfaces should be done after getting the boundaries right, because they make the boundaries more rigid
• “architecture violations” (I’d probably say “layer violations”) are a good place to start because they have pretty rough granularity and help define the general shape of the system
• Always tackle dependency violations before looking into privacy
That last point is why we removed the privacy violations feature from packwerk.

38

yeah… privacy is last in our list of concerns

39

Message originally sent by slack user U70TIGAX94P

See also my blog post on the topic (section “Balance Encapsulation With A Simple Dependency Graph”)

https://shopify.engineering/shopify-monolith

40

architecture → dependencies → privacy. And I don’t think privacy will be a goal for most packs.