Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Module Canvas driven by component aspect of a module #11

Closed
odrotbohm opened this issue Jul 18, 2022 · 0 comments
Closed

Module Canvas driven by component aspect of a module #11

odrotbohm opened this issue Jul 18, 2022 · 0 comments
Labels
in: documentation support Documentation generation type: enhancement Major enhanvements, new features
Milestone
0.1 RC1

Comments

@odrotbohm
Copy link
Member

The current structure of the Module Canvas is driven be the stereotypes expressed in the module. It would be nice if we could expose the component aspect a bit more by structuring it around the following 3 segments:

  1. Provided – all exposed (public) APIs (components, services) and published events
  2. Required – all consumed external dependencies (components, services) and consumed events
  3. Internal – all non-public components and events.

Port of moduliths/moduliths#195.
@odrotbohm odrotbohm added in: documentation support Documentation generation type: enhancement Major enhanvements, new features labels Jul 18, 2022
@odrotbohm odrotbohm mentioned this issue Jul 18, 2022
Closed
odrotbohm added a commit that referenced this issue Nov 11, 2022
@odrotbohm
GH-11, GH-66, GH-67, GH-68 - Improve module canvas.
d96263f 
Overhauled the module canvas in various ways. By default, we now skip "empty" rows. In other words, if we do not find any published events for example, we skip the entire row. CanvasOptions.revealEmptyRows() can be used to keep those empty rows around. We now also expose all value types and Spring bean references.

Refactored the dependency lookup APIs on ApplicationModule. Both DependencyType and DependencyDepth are now top-level types. Also, ApplicationModuleDependency and ApplicationModuleDependencies were introduced as explicit types. In the course of that, ApplicationModule.getDependencies(…) has got its return type changed from List<ApplicationModule> to ApplicationModuleDependencies. The internal ModuleDependency type has been renamed to QualifiedDependency.
@odrotbohm odrotbohm added this to the 0.1 RC1 milestone Nov 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
in: documentation support Documentation generation type: enhancement Major enhanvements, new features
Projects
None yet
Milestone
0.1 RC1
Development

No branches or pull requests
1 participant
@odrotbohm