You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.
In order to use Moduliths as a preparation for a monotlith to micoservices migration, it would be useful if any transactional context across modules appears in the report.
The text was updated successfully, but these errors were encountered:
That's an interesting suggestion. I wonder if you could elaborate on what this could look like. Currently we only "report" violations that are usually verified for in a test and which would break the latter. I don't think we'd want to break a build because of that because it might actually be generally acceptable if convenience trumps decoupling.
In general, we'd need to find components that invoke other components from other modules within a method marked as transactional. Tricky bit could be that that invocation of the other module component might be hidden behind an indirection: @-tx-method -> private method -> method invocation on other module component. Also, the invocation might be hidden behind an event publication that exists a listener for in the other module.
In order to use Moduliths as a preparation for a monotlith to micoservices migration, it would be useful if any transactional context across modules appears in the report.
The text was updated successfully, but these errors were encountered: