What's the point of com.saasovation.identityaccess.application.command?

[monrealis]

What's the point of having different packages com.saasovation.identityaccess.application and com.saasovation.identityaccess.application.command?

• If you use AssignUserToRoleCommand, you use AccessApplicationService. If you use AccessApplicationService, you use AssignUserToRoleCommand. If classes are used together, it makes sense for them to be in the same package. The Common Reuse Principle: "Classes that are used together are packaged together". See http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod.
• Inside com.saasovation.identityaccess.domain.model services and other types of classes (entities, ...) are in the same packages. Why should it be different inside com.saasovation.identityaccess.application?

[VaughnVernon]

@monrealis They are in the same package, but for readability there is a sub/child package for the command types. If you don't like it feel free to do as you prefer. One factor here is Java. With Java each top-level public class must be in its own .java file. If another language were in use I might decide that a single source file such as Commands.cs might be better. One other option for Java is to put all the command classes inside a Commands with static declarations. I have taken that approach in the vlingo/platform code: http://github.com/vlingo

https://github.com/vlingo/vlingo-examples/blob/master/vlingo-iddd-collaboration/src/main/java/com/saasovation/collaboration/model/forum/Events.java

Every choice me make has tradeoffs. I don't consider having a sub/child package with a clear name command to be difficult to understand or reason about. Under a given set of constraints, including the goal of readability, this is a worthy choice.