Hello!
We’re reached a point where we feel we need a clear naming convention around which packs are intended to be consumed by other packs.
For example, we have a “Texting” pack which provides an API for sending text messages as well as some HTML ERB view template partials that other packs may want to render. This sort of pack is “public” or external facing to the rest of the application (this doesn’t mean EVERYTHING in the pack is automatically public, it may have some encapsulated internals).
We also have packs that other packs should not depend on. These are “customer feature” packs, which hold services and controllers that are feature specific and would not be reused. This pack is “private” or internal facing to the rest of the application.
I’m aware of the packwerk-extensions privacy and visibility checkers and we will probably use them. But we feel like there’s probably industry naming standards that would help communicate the design and easily create alignment and understanding.
Our current “taxonomy” in naming is causing a lot of confusion as different people take away different meanings from “Core” and “Domain”.
Any advice on resources I should look at? What standards do you use?
Thanks!
Sarah
Have you seen the layer checker?
It allows you to establish layers, like “utilities” or “service” and have higher order rules around how those layers can depend on one another. Maybe this would solve a portion of the need?
In terms of naming… I haven’t heard many standards. There are some ways I think domain agnostic naming conventions can help, such as layers maybe, but I think most of the rules will be part of the domain specific language embedded in your pack names and architecture rules. Not super helpful but I haven’t found a great substitute yet for just having really clear domain modeling.
1 Like
What @AlexEvanczuk said!
We have also, in places, started using a nested folder structure to hide / group packs. We use it for layers and some other structures. That said, I would thoroughly reflect on doing that because it comes with deeper trade offs.
Ya, I’m leaning against doing the nested folder structure because it works against our goals of smaller sandboxes for Bazel test selection. I think though that the visibility checker would be sufficient in our case for the hiding, but haven’t tried it yet.
Yep, that’s one of those tradeoffs.
Note that you can the layers extension doesn’t require nesting. We use them together to an extent, but you don’t have to.