Generator-jhipster: Allow to group entities by logical names (or "package by feature")

[jdubois]

We have many people asking to have JHipster generate entities (and probably also repositories/services/endpoints) in business packages, or "package by feature":

• Today we generate Spring apps using "package by layer", so each technical layer is a package. This isn't considered a good practice by people in the DDD movement, or by people developing the front end (our Angular style guide uses package by feature, so we are not consistent).
• "package by feature" also causes a few issues: you will get package tangling and probably a bad Sonar score. Also you will probably have trouble with JPA and lazy-loading. And traditionally, Spring applications use package by layer.

So it's not all black and white... For me, we have 2 options for this at the moment:

• Do a microservice by feature. This isn't a perfect answer, but if you have a clean domain model which can be splitted in a microservice, that looks like a good idea to do it.
• Refactor the generated code: you just move around your code into business packages using your IDE. So you have what you want (awesome!), but you won't be able to re-generate your app easily (but that's not a huge issue as you are doing business code, and thus take control of the code: that's what happens all the time on the front-end, and you don't want to generate those parts any more).

Now I would like to add 2 new concepts to go further, and I would like your feedback (ping @hdurix as this something he knows well) on it:

• We could add a new attribute do entities, called "feature". You would group entities by features, and all those entities would end up in the same "feature" package. For example, you tell entity A and B are in the "invoice" feature, and they end up in the "com.myapp.invoice.domain" package. It wouldn't be very hard to do, and solve a big chunk of this issue.
• We could also add some kind of .jhipsterignore file, where we tell JHipster which entities we don't want to be generated again, as we took control of them.

[PierreBesson]

@jdubois About the idea to mix and match the two styles (having package by feature only for entities), I think this will not satisfy the people who want this feature.

Personally I think it's doable to create an option to choose between package by layer and package by features globally for an app. It would further complexify the code but in the end it's mostly a matter of :

1. Generating the files in the correct folders
2. Generating the correct import statements (and in the case of packageByFeature there are no imports as the classes are located in the same package)
3. Generating the correct access modifier (public vs package visiblity)

[deepu105]

I don't think we should do package by feature on java side, its more
trouble and not worth whatever benefit that is claimed also it only makes
our code more complex

On Fri, 1 Feb 2019, 5:32 pm Pierre Besson <[email protected] wrote:

@jdubois https://github.com/jdubois About the idea to mix and match the
two styles (having package by feature only for entities), I think this will
not satisfy the people who want this feature.

Personally I think it's doable to create an option to choose between
package by layer and package by features globally for an app. It would
further complexify the code but in the end it's mostly a matter of :

1. Generating the files in the correct folders
2. Generating the correct import statements (and in the case of
   packageByFeature there are no imports as the classes are located in the
   same package)
3. Generating the correct access modifier (public vs package visiblity)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/9171#issuecomment-459782263,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlFzh6akARia_qByXOFH-17CG6Sz5qks5vJGwCgaJpZM4ad_8M
.

[hdurix]

Indeed, package by layer is not considered as a good practice in DDD world but package by feature is only a small part of the concept. Other aspects are also present (and of highest priority?) in DDD: domain object protection, hexagonal architecture, event sourcing, CQRS, all of them would be quite difficult to manage when generating the app as it depends on the business.

In the future, trying to provide an option to be more DDD compliant could be valuable. For that, what could be really interesting would be to ask to someone knowing DDD what are the steps used after generating the app with JHipster to transform the classic Spring application to a DDD compliant app, it could be something like:

• creation of domain object in front of @Entity (containing only infrastructure code: database)
• split Spring entities in DDD entities, value objects and aggregates
• add business logic inside domain objects
• create domain events to update the domain (event sourcing)
• separate commands from queries (CQRS) in controllers & services
  If we have this list, we could eventually have an idea about what could be the steps to be ready for generating a DDD application.

That's why I'm afraid that only creating package by feature would be enough for people asking for package by feature. And only managing package by feature might not be better than the current method: only generate then refactor the code to be DDD compliant.

I agree with @deepu105, our code would be more complex, but it could also bring a lot of value.

[jdubois]

OK, thanks a lot everyone for the feedback, that wasn't such a great idea: let's close this!