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.

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

Define strategy to avoid need for over declaring architectural concepts #19

Open
odrotbohm opened this issue Oct 2, 2020 · 2 comments
Labels
module: architecture Architectural style related support module: ddd Domain-Driven Design related support

Comments

@odrotbohm
Copy link
Member

odrotbohm commented Oct 2, 2020

jDDD artifacts are designed to be usable as independently as possible. E.g. the onion architecture annotations are usable completely without the building blocks annotations in jDDD Core. That however also imposes an interesting challenge. Let's say your project combines the two artifacts. To benefit from both the declarations, you would now have to do the following:

@AggregateRoot // from jddd-core
@DomainLayer // from jddd-architecture-onion
class MyAggregate { … }

This is basically expressing the same thing twice as you could argue that from the fact, that MyAggregate is an @AggregateRoot, it belonging to the domain layer is implicit.

A very direct solution for that would be to meta-annotate @AggregateRoot with @DomainLayer. However, that would introduce a dependency in the wrong direction and kind of imply that jDDD Core annotations would imply onion architecture, despite that technical dependency not be a strong one at runtime (as annotations can be missing without failure). It would be logically more consistent to transparently "annotate" MyAggregate with @DomainLayer if it is annotated with @AggregateRoot and jDDD Onion Architecture is in use.

There are two options to achieve that:

  1. We could leave that semantic derivation to downstream tools that can embed such rules into the implementation of their analysis. E.g. jQAssistant could easily add that additional metadata to its model based on that rule. I'd love to see that in those tools (ArchUnit, too) but at the same time it means that other tools evaluating the annotations only would not see those "derived" annotations.
  2. Just like we already prototypically add technology specific annotations derived from metamodel ones in the jDDD JPA Plugin, we could use ByteBuddy to declares these additional annotations transparently by implementing a plugin.
  3. Lombok seems to be getting a meta-annotation feature soon.
@odrotbohm odrotbohm added this to the 1.0 milestone Oct 19, 2020
@odrotbohm odrotbohm added module: architecture Architectural style related support module: ddd Domain-Driven Design related support labels Oct 19, 2020
@odrotbohm odrotbohm modified the milestones: 1.0, 1.1 Oct 22, 2020
@odrotbohm odrotbohm modified the milestones: 1.1, 1.2 Feb 19, 2021
@odrotbohm odrotbohm removed this from the 1.2 milestone Mar 15, 2021
@ikysil
Copy link

ikysil commented Mar 16, 2021

There are way too many @Domain... annotations defined in the jmolecules to make the semantic derivation safe. I doubt it will be safe to derive ALL of those for @AggregateRoot:

  • @DomainLayer
  • @DomainServiceRing
  • @DomainModelRing
  • @DomainRing

A set of the ArchUnit rules enforcing particular combination would be more useful, as projects then may decide which combination (one or many) fits the context.

Also, the dependency on the implicit annotations makes architectural checks fragile. I would insist on explicit declarations in the projects I'm working for.

@odrotbohm
Copy link
Member Author

Thanks for the feedback, Illya. I share your concerns and it's very likely that we end up doing just nothing for now. It's still good to have the ticket around to gather feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
module: architecture Architectural style related support module: ddd Domain-Driven Design related support
Projects
None yet
Development

No branches or pull requests

2 participants