What should be said when asked about the architecture of a project/application?

Question

Java

Hi all. Often, at interviews they are asked to talk about the architecture of the application / project at the current place of work, in fact, I don’t quite understand what “architecture” means?
For me, architecture is, let's say, how the components of the system are connected, in what form they are stored.
For example, there is an application server and some components are stored as ejb in a container, different subsystems communicate using jms.
In general, it is interesting to listen to your opinion, which could explain what should be emphasized when describing "architecture" and what is generally meant by this concept, but please, without references to the wiki.

Answer 1

Answer "we try to adhere to a clean architecture, but we have so much legacy code ...")))
In general, Robert Martin wrote that the main advantage of OOP is that it allowed us to split the system into parts-plugins. Those. The system is divided into fairly independent parts that interact with each other through fairly stable interfaces.
Architecture is how these plugins are laid out in the system. Those. layers are obtained. The important point is that the inner layer does not depend on the outer layer. Therefore, there is independence from the implementation of external layers. And to this appears a comparatively simple testing of parts of the system. i.e. (on the example of the clean architecture described here is not at all accurate and very chaotic)
For example, a clean architecture has a recognizable structure
in the center of business logic, around things that provide data to the logic, saving this data ... around various services, displaying in ui, working with the network, with the database, etc.
The architecture story should be about breaking the system into parts and how these parts depend on each other. And what are the benefits or problems of such partitioning.
Also often accompanied by questions "how the interaction of layer A with layer / component B is organized." It is more likely to check whether you know the solution to typical problems. And templates. e.g. MVP, MVC, MVVM, Repository etc.

Answer 2

The question itself is too general. In response, you usually need to ask clarifying questions. About the technology stack, application type, level of detail, layers, etc. ask. And to focus on what is really interesting to the interlocutor. You can also talk about everything superficially and understand from the reaction what is really interesting, but it’s still better to ask.
The most serious mistake in technical interviews: start answering a question without fully understanding what you were asked about. Ask clarifying questions, involve the interlocutor, talk out loud, etc. A normal technical interview tests your ability to think.
In general, a universal recipe for any discussion, and not only at an interview: to determine what and why the discussion is at all. Those. define terms, clarify boundary conditions, levels of detail, what we want to achieve, etc. But, I warn you right away, people will not love you for this :)

Answer 3

There are many things to tell. It is enough to read Martin Fowler's book "Architecture of Enterprise Software Applications", from which everything will become clear.
In a general sense, an architecture is a way of organizing a system, such as an n-tier architecture. Architecture in a detailed sense - the design patterns used and for what purpose they are used, for example, using the Repository pattern to implement basic methods of interacting with the database, such as CRUD.
For games, for example, architecture also represents the way the system as a whole is organized and the design patterns used to organize each component of the system individually. But it is better not to compare with corporate applications.