I dream of a world where a Product Model can be generated from the organization of the backend files that respect the Domain-Driven Design (DDD) approach. That would quickly enable Product people to formalize a shared language from real code, and not spend hours philosophizing about why X should be named Y. Alas, this time has yet to come.

Indeed, one of the hard things to do in product development is to come up with a naming convention for your app that makes sense to everyone. Engineers, designers, and everyone else on the team need this shared language to talk about the product.

Another thing that is important for Product Managers is the ability to quickly conceptualize requirements for a feature or a product. Sometimes, user stories are too vague or incomplete.

Taking free inspiration from DDD, which states that in naming, the engineering logic must be as close as possible to the real-world, business logic, we can imagine the following model:

Domain Layer

This is where we name the entities and concepts that power the product. Domains are where the unique business logic is expressed. Say you are building an ecommerce app, you might have Cart, Accounts or Payments. If you're building an AI companion dating app, you might have Profile or Chat.

Infrastructure Layer

To me, this is where the backend orchestrates services that talk back and forth with the database. This is where I might refer to purely technical, non-visual elements such as a matching algorithm or a dedicated LLM logic.

Application Layer

This is the traditionally used layer when Product people think about products. This can capture interaction-based, user-centered flows that blend different objects from the Domain and Infrastructure layers, such as Sign Up or Add Item to Cart. 

In short, because software applications are complex systems, thinking about the Application layer is not enough.

Product people should take into account the impact of a new feature in conceptual terms (Domains) and in technical, non-visual terms (Infrastructure).