Can you explain how to do X with Deptrac? (Deptrac is starting a blog)

[patrickkusebauch]

Deptrac is starting a blog on its official documentation site. As a part of it, I am collecting ideas for topic people would like to hear about. Feel free to add your ideas as comments in this issue. I will kick off the process by writing some that I have observed:

• How to analyze dependencies on vendor packages (based on #1182)
• how to handle complex architectures like DDD which require handling different "levels" of layers (different ways of slicing the classes and defining the dependency rules). Since classes cannot belong to multiple layers, the only solution I found was to use separate configuration files but it might be a better solution (From Slack)
• Writing extensions (custom rules, formatters, and collectors) - example: "Is it possible to set a rule that allows referencing a foreign class but not instantiating it?"
• Using custom layer attributes for custom rules (based on #837)
• Dealing with domain and integration events in DDD architecture
• Multiple "views" of the architecture/ creating multiple slices by using multiple Deptrac config files

[patrickkusebauch]

How to prohibit an instantiation of a class (from Slack):

Hi folks, I want to restrict the usage of a given class: allow referencing (eg. usage in "use" statements or arguments) but not its instantiation (calling constructor). So I tried to create a custom rule but the official documentation (https://github.com/qossmic/deptrac/blob/main/docs/extending_deptrac.md) is very succinct and doesn't provide useful examples. Do you have some additional documentation or code examples?

[patrickkusebauch]

Explain how to create layers where token cannon reference other tokens from the same layer: https://github.com/qossmic/deptrac/issues/1278

[gennadigennadigennadi]

https://qossmic.github.io/deptrac/blog/2023-05-11_PHP_configuration/ FYI: @patrickkusebauch

[jorgsowa]

how to handle complex architectures like DDD which require handling different "levels" of layers (different ways of slicing the classes and defining the dependency rules). Since classes cannot belong to multiple layers, the only solution I found was to use separate configuration files but it might be a better solution (From Slack)

I'm awaiting this topic. It's not straightforward how to define modules with interfaces/contracts without marking all the files with a @internal comment.