The reason for ***ApplicationServices?

[gzsombor]

As I see, all the ***ApplicationService are just creating a ***ModuleFactory and call it in their buildXYZModule function.
It seems, that we can remove them all, and add @Service annotation to the ModuleFactory, and use it directly in the ***ModuleConfiguration.

[DamnClin]

This would break the code architecture by introducing a framework dependency in the domain and making domain framework dependent.

This is explained in the hexagonal architecture documentation.

It is totally a possibility but it means switching to a new architecture because this one would not be relevant anymore

[gzsombor]

Sorry, if you refer to this, it's very light on specifics, let alone the benefits what kind of benefits does the separation of the ModuleFactory and ApplicationService brings?
You can't use any ModuleFactory without it's dependencies and emulating this dependency management with the ApplicationService classes seems a very bloated, poor man's Springs solution.

[DamnClin]

Yes, I'm refering to this. You can also read this from the original architecture author.

Hexagonal architecture is meant to protect the domain. If you remove this there is no point in this code architecture. This mean you can also delete the rich domain model because it will become bloated over time (without any protection).

This may sound stupid but I have seen it many times in companies I'm working with: it is worth it to protect the domain model, no matter what.

On the frontend, we are going around this by injecting the secondary port in the primary adapter which is totally fine since the domain still don't depend on any framework but, on the backend it's not a good solution to do that.

I'm not saying that choosing hexagonal architecture & rich domain models was a good idea. I'm saying that you need some code architecture to protect the domain otherwise it's useless to do it.

We can discuss the pro & cons of this coding style but they are the root of JHipster Lite so the value of the discussion won't be that great

[gzsombor]

There is no domain protection happening around the modules, so I don't understand your point. The ApplicationServices dont adapt to anything, they just pass the input to the Factories. (Even if you are saying that JHipsterModuleProperties class is part of the domain, or part of the infrastructure, they are used as is, so no adapters or no conversions are needed)
As public classes and methods are used heavily just for these forwarders, they eradicate any sense of 'domain' protection.

I think, even if you have a convincing theory, that you can follow, and promise some advantage:

• you can challenge, if that promise is true, or it is worth the effort.
• you can challenge, that when you turn it into a practice, on a specific task, your implementation really follows the suggestions of the theory - or if it makes sense to apply the theory

So I'm not saying, that choosing hexagonal architecture was wrong, or using rich domain model is not nice or effective.
I just want to say, that :

• Adding an additional layer of 'ApplicationService' doesn't make sense
• Also, separating the domain model of the internals of the module, and the domain model of the whole engine, which applies the changes on the project, doesn't seem necessary/plausible/beneficial, so even in the future, further adapters won't be needed.

I also saw a couple of times, when someone thought they should build a future proof architecture, it is very easy to balloon up the lines of code with 2-3 times, without any benefit (just the constant burden, that even the most basic change of adding a new field needs modifying ~100 LOC)

[DamnClin]

In the current state, adding Spring annotation in the module factories is making the domain dependent to the framework since module factories are part of the domain model (they are Factories, as defined in Evans 2003), they are the core business value of a module.

We are protecting the domain of any external dependency, why are you saying that this is not a domain protection?

ApplicationServices are not meant to adapt anything to anything, this is not there purpose, adaptations are done in the adapters (primary or secondary).

This convincing theory is something I'm practicing on a daily basis for years. In some missions, I'm a technical coach so I can work with hundreds of people on that and, as time passes, I'm more and more convince of the benefits of this peculiar approach since it is the one allowing true decoupling between business value and technical details. Here are some customers interview (in french) after some time of coding that way :

• https://www.youtube.com/watch?v=8x9_hpL0jj0
• https://www.youtube.com/watch?v=JvrNRbZhtHo
• https://www.youtube.com/watch?v=EOAv21VSkrU

The goal is not really to have a future proof mechanism, the goal really is to decouple domain from technical needs to reduce the accidental complexity.

[gzsombor]

Sorry, as you haven't specified previously, what you consider framework in this context of code-generation modules, I assumed that you are referring to the code, which is outside of the module, the code which introspect the module, and provides the necessary information to act on. I was wrong, my bad.
So you are more worried about using Spring inside the domain code, if I understand you correctly.
But if this is the case, it's pretty easy to avoid that, still no need for a separate ApplicationService and ModuleFactory.
Just modify the ModuleConfiguration to something like this:

@Configuration
class XModuleConfiguration {
  @Bean XModuleFactory xModuleFactory() { ... }

  @Bean
  JHipsterModuleResource xModule(XModuleFactory xModuleFactory) {
    return JHipsterModuleResource.builder()....factory(xModuleFactory::buildMyModule);
  }
}

[DamnClin]

I consider Spring as a Framework.

Yes, you can do that (this is kinda what we do on the frontend) or you can create a domain annotation and ask spring to watch it but it only works for modules, not for other code requiring orchestration, transaction or authorization management.

The tradeoff isn't obvious to me. Sure we cut 3 LOC for each module but at the cost a specific logic that should not be replicated outside of module generation.