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

Discussion: Cohesive package naming conventions #176

Open
notjuanortiz opened this issue Nov 7, 2019 · 1 comment
Open

Discussion: Cohesive package naming conventions #176

notjuanortiz opened this issue Nov 7, 2019 · 1 comment
Labels
discussion An issue that requires in-depth discussion among contributors.
Milestone

Comments

@notjuanortiz
Copy link
Contributor

notjuanortiz commented Nov 7, 2019

I would like to discuss moving towards a more cohesive package naming convention for the entire project.

There's typically two schools of thought on this topic. The first being package by layer. Naming your packages according to their function architecturally rather than their identity according to the business domain. Our packages would be horizontal slices rather than vertical.
Example(s):

  • io.luna.game.item responsible for business logic
  • io.luna.database.item responsible for CRUD operations
  • io.luna.network.item contains network messages
  • io.luna.ui.item contains UI components and interactions

And the second being package by feature. Naming your packages according to their business domain identity. Doing so, we'd be putting every class that has to do with that vertical slice of functionality into that package.
Example(s):

  • io.luna.item.container.shop
  • io.luna.item.container.bank
  • io.luna.item.container.inventory

The current state of the project is a culmination of both approaches which makes deciding which package to add new features to a bit confusing. Where would I add a persistence implementation for shops when the business logic for shop is in io.luna.game.shop and all persistence implementations are in io.luna.game.mob.persistence? It would be great if we could pick a single approach, making contributions a bit more intuitive.

@notjuanortiz
Copy link
Contributor Author

notjuanortiz commented Nov 7, 2019

This is somewhat related to #56 and #74.

@lare96 lare96 added the discussion An issue that requires in-depth discussion among contributors. label Nov 8, 2019
@stale stale bot added the wontfix An issue that went stale or won't be resolved. label Jan 7, 2020
@luna-rs luna-rs deleted a comment from stale bot Jan 7, 2020
@stale stale bot removed the wontfix An issue that went stale or won't be resolved. label Jan 7, 2020
@stale stale bot added the wontfix An issue that went stale or won't be resolved. label Mar 7, 2020
@stale stale bot closed this as completed Mar 14, 2020
@lare96 lare96 removed the wontfix An issue that went stale or won't be resolved. label Mar 15, 2020
@lare96 lare96 reopened this Mar 15, 2020
@luna-rs luna-rs deleted a comment from stale bot Mar 15, 2020
@luna-rs luna-rs deleted a comment from stale bot Mar 15, 2020
@lare96 lare96 added this to the v0.5 milestone Dec 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion An issue that requires in-depth discussion among contributors.
Projects
None yet
Development

No branches or pull requests

2 participants