supported bounded context

[chicuongle]

personally I think this plugin is very useful. I've used this plugin in our projects with hundreds of modules and to guarantee architecture style of product. Thanks for an amazing work!

Our product is quite big with a lot of different domains and therefore context boundaries between different domains are required. That means we do need some rule like: services in domain A should not depend on any other services in domain X. With module type (name alias) I can declare rules inside one domain. But for rules based on different domains (bounded context) I have no idea how to use this plugin to support this feature. Any help, advice ? Thanks

[chicuongle]

I can imagine following use case:

• if there is no specific bounded context relevant for rules (allow/restrict), then rules are valid for all modules
• if there is a specific bounded context relevant, then rules should be applied only for modules inside bounded contexts
• rule can be declared to applied different bounded contexts. For example, for by using the Hexagonal Architecture style, OutGoingAdapter in one bounded contexts are not allowed to have dependency on other OutGoingAdapter in other bounded contexts

[jraska]

hi @chicuongle , sorry for late reply I missed the notifications. 😞

If I understand, you mean applying different set of rules for different sets of modules?

• I can imagine it working with the moduleNameAlias and applying some regex rules on the alias which would be composed based on your domains 🤔
• Other option I can think of is applying the plugin with different rules for different modules - as you can see here, the plugin validates whole dependency graph when applied to the root project and typically also whole graph when applied to the top level :app module. This is the most common use case. However it is possible to apply the plugin on each module individually and the rules will be applied only on dependency subtree of that particular module.

[jraska]

Hey, I will close the issue for now - please if there is more to follow up, reopen the issue.

Thanks

[chicuongle]

Hi @jraska thanks for your reply on my question. Actually, I've tried same idea as you've shown https://github.com/jraska/modules-graph-assert/issues/175#issuecomment-1218139486 in the first point: using alias name as bounded context and using different regex for different bounded context. But there is a point in the current implementation: we can have only one alias name. This fact causes to have long, complex alias name to achieve our goals.

The idea in this request is to allow different regex in different bounded contexts in a gradle project. Architecture of applications define application components as well as different types of components. Architectures defines rules of dependencies between modules, for example: module type A can not depends on module type B, etc. But if we want to define some rules like:

• in context X, module type A can not depends on module type B. In other contexts this is possible
• module type A can not depends on each other if they are in different contexts.

Actually, I do think that multiple alias names can resolve my concern some how. Similar concern related to layers in architectures can be resolved. By using multiple alias name we can define different architecture point of views, and therefore declare more effective rules for our components.

So could you check again about multiple alias names and re open this issue? I do not have permission to re open this issue

[jraska]

Hey, thanks for further explanation of your case.

The idea in this request is to allow different regex in different bounded contexts in a gradle project.

One way I could see how you could implement it for your use case is conditional configuration - we can imagine the context to be a variable(or anything else) and then your Gradle code could look like:

if(context == ContextA) {
  moduleGraphAssert {
    ...
  }
} else {
  moduleGraphAssert {
    ...
  }
}

Or something similar - basically you can apply some logic to conditionally apply different rules.

About the multiple aliases

I see there some complexity in terms that we would have to somehow decide on priority between aliases and then handle their combinations for the current functionality. Example with defined behaviour would help to explain the case or I think what would be better would be a PR with ideas how to implement this to discuss further, because I can't still imagine how the code for our case would look like 🤔

Though as far as I understand it, we would add a whole new dimension to the plugin which adds extra dimension of complexity. So far I'm not keen to go that route as I believe the complexity is not worth it for the amount of cases which would match for this plugin.

[chicuongle]

Hi @jraska, I'll try to build a sample project after Hexagonal architecture to demo idea with multiple alias. Question with priority is interesting because even with current implementation we do have to decide: if allowed rules should be applied first or restricted rules. Another question here is: do we really need a priority or just apply all rules (randomly), until no more violations occur as well as no conflicts between rules exist?

[jraska]

Question with priority is interesting because even with current implementation we do have to decide: if allowed rules should be applied first or restricted rules.

Yeah exactly - the decision is to keep these checks independent - explained here.

Another question here is: do we really need a priority or just apply all rules (randomly), until no more violations occur as well as no conflicts between rules exist?

We would have to go either with priority deciding which alias applies to each module during check - in cases we don't have some scope - context choosing which alias would apply - or possibly we would have to assert all combinations. 🤷

Anyway I think the conditional configuration explained here could be the best way to achieve your goals.