Validate Folder package Structure

I want to validate my folder structure for one of the functional modules and need an opinion on it.

MicrosoftTeams-image (2)
each module contains a similar but separate structure as following:
parent level folders: application, domain, infrastructure, resources.
resources: Controllers and DTOs
Application: Application Services, commands, queries, repository interface, Event Handlers (those which write to read database using repository interface), Query Handlers (which read data from read database using repository interface).
Domain: Aggregates, Entities, Events, Domain Services
Infrastructure: Repository Implementation class

Please suggest, should I use such a structure for the functional module.

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, …

First of all, Thank you for the answer and sorry for the delayed response from my side. I completely agree with your point that functional modules are more important than technology/architectural components. I have already taken care of that part and within one bounded context or module (i.e. challenge), I created such folder structure and wanted to know the feedback. Especially with the repository part, e.g. whether it should be at the application level or at the infrastructure level. or the interface should be at a certain place and implemented at some other place.