https://github.com/joht/discover-types-cdi-axon-demo-configuration
example axon framework java ee configuration using "discover-types-cdi"
https://github.com/joht/discover-types-cdi-axon-demo-configuration
Last synced: 3 months ago
JSON representation
example axon framework java ee configuration using "discover-types-cdi"
- Host: GitHub
- URL: https://github.com/joht/discover-types-cdi-axon-demo-configuration
- Owner: JohT
- License: other
- Created: 2018-11-15T21:07:17.000Z (over 6 years ago)
- Default Branch: master
- Last Pushed: 2021-09-11T13:06:27.000Z (almost 4 years ago)
- Last Synced: 2025-01-27T07:42:21.012Z (5 months ago)
- Language: Java
- Size: 12.7 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE.md
Awesome Lists containing this project
README
Axon Framework configuration example for CDI (Java EE / Jakarta EE)
==============
This project demonstrates, how "discover-types-cdi" can be used to configure axon framework
inside a Java EE / Jakarta EE project.
It also demonstrates,
how the domain code could be decoupled as much as possible from axon framework (Version 3.3.x).
Axon framework is written very modular and does not need
to be integrated inside a Java EE Project using an "all inclusive" CDI extension.
Although it may be practical to do it that way and let it look similar to spring,
it is not necessary to do so.
Producing all kinds of beans and therefore publishing every bit of the configuration
to be called from theoretically everywhere in the domain code can cause problems.
# Hexagonal Architecture
The idea behind this is inspired by "hexagonal architecture" or "ports and adapters".
The "infrastructure"-package contains the port (or "boundary") to the domain and
is implemented by an adapter to connect axon.
If the domain code, for example, wants to send an domain event,
it uses the locally defined ubiquitous language represented by internal services (e.g. ExampleEventBusService, not axon directly),
which delegate the request to axon framework (axon framework event bus).
To decouple it further and get it closer to "hexagonal architecture",
"ExampleEventBusService" (and alike) would be changed to interfaces and their implementation
(axon framework adapters) would be placed in a different module.
Since it is not planned to e.g. introduce an axon mockup for integration testing or get
completely rid of the build dependencies (so that really nobody can reach for axon framework dependencies directly in the domain module), these steps are skipped for now.
Further complexity should only be introduced when needed.