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

System Design
41

Message originally sent by slack user U7213XMGS3H

I’m gonna take all this back to our Packwerk working group and maybe rethink our levels a little bit

42

Message originally sent by slack user U70TIGAX94P

architecture → dependencies → privacy

To me architecture is mostly dependencies too, just at a level of granularity that is not specific packages but groups of packages

43

Message originally sent by slack user U70TIGAX94P

Love the idea of levels, just disagree with the ordering.

44

Message originally sent by slack user U7213XMGS3H

<@U70TIGAX94P> what would an ideal order be in your head

45

Message originally sent by slack user U70TIGAX94P

Establish structure starting from coarse and working towards fine grained

So essentially what @oboxodo said.

public interfaces are “how do I call this”, it’s a pretty specific question. Getting dependencies right, especially if you avoid cyclic ones (as packwerk forces you to do), will help you define the responsibilities in the first place.

The architecture stuff is just one level more coarse than packages, so it’s a good way to get started with dependencies.

46

<@U70TIGAX94P> totally agree. Architecture is just a means of grouping packs and focusing on the “big stuff” first. Divide to conquer! haha. But please tell me more about why you disagree with the ordering.

47

Message originally sent by slack user U7213XMGS3H

So…

  1. Stuff in packs with an established layer
  2. No layer violations
  3. No dependency violations
  4. Public API defined
  5. No privacy violations (+ everything I have in level 3)
    Is that the gist of what you’re saying (more or less?)
48

I think that looks good.

49

Message originally sent by slack user U7213XMGS3H

This thread has been super helpful. I’ll take this back to our folks and let you know how it goes

50

But I’d love opinions from other devs with more experience modularizing stuff here.

51

it’s been useful for me too! haha.

52

BTW… after you put a layer on each package.yml … run this and enjoy your mess :sweat_smile::

bin/visualize_packs --no-legend --no-dependencies --no-privacy --only-todo-types=architecture > packs.dot && dot packs.dot -Tpng -o packs.png && open packs.png
53

Message originally sent by slack user U7213XMGS3H

One thing came up internally when I showed them your layers @oboxodo… it feels like it’s possible for something the be deprecated and utility or deperecated and feature… i almost wish there was an easy way to make deprecated expressed differently. We could put it in the metadata, but then we’d have to write our own little bot to check for violations… just something to think about. we will probably end up doing what you did anyway

54

Sure. A pack would never really start in Deprecated layer. You’d move a pack from some other layer the day you decide that pack shouldn’t be used anymore.

55

But you don’t have to have a Deprecated layer (or any specific layer FWIW).

56

Someone else suggested that to me (I think it was @stephan) and it reasonated for us for our current state in the project.

57

Normally the pack at the top layer would be just your main app.

58

Message originally sent by slack user U7213XMGS3H

I think this is my response proposal based on everything I’ve heard. I decided not to go with 5 levels and merged the architectural violations and the dependency violations into one level. It just seemed like easier to conceptualize organizationally with fewer levels.

59

I like that table :ok_hand:. I’m aiming for Level 2 on all packs. Only after that, reevaluate if we want to keep pushing for higher levels on a pack by pack basis. Just getting to level 2 is going to be huge.

60

Message originally sent by slack user U7213XMGS3H

so you’re trying to get to 100% L2 before advancing anything past?