Hello and welcome @sandip_patel
I moved your question to #architectural-concepts as it’s not really about Axon Framework.
I’m not sure what exactly is your goal with this package structure and I will try hard to not rush to (mis-)judge it. But I must say it does feel awkward at first look.
I published a blog post a while ago that you may find interesting. I’m referring to it here because the main issue I have in both cases is the same - the structure does not communicate to me what is this piece of software about.
Here is a quote from Uncle Bob’s Screaming Architecture:
When you look at the top level directory structure, and the source files in the highest level package; do they scream: Health Care System, or Accounting System, or Inventory Management System? Or do they scream: Rails, or Spring/Hibernate, or ASP?
To be honest I can’t really tell what the package structure you propose screams.
What I personally get from it is that:
- there is
challenge
- the
challenge
encompasses exactly one domain
- the most important part of the
domain
is to separate aggregates
from entities
from events
from services
from …
- to solve the
challenge
one needs infrastructure
- there are some sort of
resources
needed to solve the challenge
- the
challenge
is solved by exactly one application
Was that the message you were trying to communicate by structuring things this way? If so that the structure is perfectly fine. But my guess is it probably wasn’t your intention. Yet, it’s likely the most anyone (not having the full context) will get out of it without a deep dive into the source code.
In summary, if the fact that something is event
, service
, repository
, command
, query
, … is more important than the business concept it deal with - than by all means this structure makes perfect sense. In most applications I’ve built though, the business meaning of a component was always far more important. Then the business relationships between components draw the boundaries which naturally leads to respective code being split into packages, modules, applications, systems, clusters, …