Naming convention for private representations of -api projects

[yg-apaza]

Currently, the private copy for a class of API project is PXyz (like PItem, PItemState, etc) or sometimes it's the exact same name with only a package difference. We should settle a naming convention

[TimMoore]

Java doesn't provide a great way to deal with naming conflicts. In Scala you can use relative package names, or import with an alias, but in Java if you have a name conflict between two classes that you need to use in the same file, your only choice is to use a fully-qualified name to distinguish between them. Since it is commonly the case that you need to convert between internal representations and external representations, these conflicts do happen in practice.

I think that's the reason why the "P" prefix was used originally in this project. Maybe that isn't the clearest convention, but I think that having a different name, not just a different package, is a good idea for this reason.

[TimMoore]

Here's what I'm thinking now... would love to hear others' thoughts on this.

• Keep the API response type names simple nouns (like they are now) Item, User, etc.
• API request types reflect the domain language: use the type of request that you're making such as UserRegistration, ItemListing, etc.
• Persistence types should use the language of Lagom's API: ItemEntity, ItemState, ItemCommand, ItemEvent
• PItemState as it exists now is an anomaly, as it is just a wrapper for Optional<PItem>. Is there any reason we can't make the ItemEntity extend PersistentEntity<ItemCommand, ItemEvent, Optional<ItemState>> directly (like UserEntity does)?

[TimMoore]

Related: #15 ... sounds like @ignasi35 and I share some thoughts.