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

Move Controller part to a separate module and use projections #16

Open
baldram opened this issue Nov 9, 2019 · 1 comment
Open

Move Controller part to a separate module and use projections #16

baldram opened this issue Nov 9, 2019 · 1 comment

Comments

@baldram
Copy link
Owner

baldram commented Nov 9, 2019 •
edited
Loading

The part related to data display should be moved to the separate module, a core one.
All data source should be a separate module.
Further, use Spring Data Projections / JPA Projections to provide the most optimal model for the frontend app.
This would be kind of CQRS and module level Single Responsibility implementation for the project.
@baldram baldram changed the title Move Controller part to a separate module and user projections Move Controller part to a separate module and use projections Nov 9, 2019
baldram added a commit that referenced this issue Nov 13, 2019
@baldram
Make application core framework-agnostic (refactoring step) #16 (#19)
5f3966c 
To get rid of using Spring specific `@Autowired` annotation where possible.

The idea is to extract the application core logic to a separate domain.
It should be framework-agnostic. There is no need to rely on any framework
for this part. Removing redundant `@Autowired` annotations should help
in further refactoring and extracting code to separate modules.

Additionally, renamed all usages of `Supplier` to avoid collision with
`java.util.function.Supplier`. The new name is `Feeder`.
baldram added a commit that referenced this issue Nov 14, 2019
@baldram
Extract the application core from infrastructure #16 (#20)
c9897fe 
The refactoring step in preparation for domain module extraction.

* Split ports and adapters,
* Cover default method of extracted interface with tests,
* Move repository to the infrastructure package,
* Move entities package into the domain

It's hard to find a good solution for extracting JPA from the core.
So JPA-entity is part of domain for now. By splitting the domain from
entities, there is a risk of loosing lazy-loading opportunities,
clear transaction boundaries, orphan deletion and so on.
For now, it's kind of trade-of by putting JPA within the core-layer.
@baldram
Copy link
Owner Author

baldram commented Nov 16, 2019

To take also this discussion under consideration: DTO projections or Interface-based Projections what also refers to Spring docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@baldram