I'm working on website and java application for my project and I'm writing report and there is question that say "What is the architecture of the project" I don't know what should I write because I don't understand what does it mean
Project Architecture – Understanding the Meaning of Architecture in Projects
Architectureterminology
Related Topic
- Plugin Architecture – What Should a Protocol Service Provide?
- Algorithms – What Does It Mean for an Algorithm to Be Sound and Complete
- C++ – Thoughts on web development architecture through integrating C++ in the future to a web application
- Java – Understanding the worker layer in software architecture
Best Answer
If they were asking for the architecture of some code or files, they might be asking about what classes there are and how they interact. However, in a project, we group classes into larger components, and these components interact.
Given that they're asking about the project, they're asking for the big picture of top level components and their interactions. Modular construction means that we bundle various kinds of things together into larger more modular units. Things within the same bundle enjoy a certain freedom of access to each others internals. Things between bundles use some kind of abstracted messaging to communicate between them, and it is significant as to when/how those messages occur. It is significant to architecture that which is persisted vs. what is computed and which component persists what (kind of) information; as are queries a component is capable of and commands it can perform.
If you are using a design methodology you might have some of these classifications already. If not, you can describe them more ad-hoc.
On one level, you explain conceptual components, their individual capabilities, and how they interact with each other (what triggers interaction; what are the contents of interactions; how one component is responsible for management and persistence of certain objects whereas another component is responsible for some others) and as wired together, these components form a project or system.
For example, if there is networking (e.g. client-server, or server-server) these should be called out as interactions between identifiable components; this can form the basis of one of the larger views of components and their interactions.
Going deeper, we can also add detail to the pictures of persistence, component capabilities, and the inter-component wirings, and, we can explain the performance/scale out (e.g. load balancing, threading models, etc..), and maintenance/failover capabilities, all of which add a lot more complexity to the conceptual picture.
Going bigger/broader, the project exists in the context of a (business) domain. The business domain is a view on the business entities and their interactions (customers, suppliers, regulators, and various other interested parties, such as advertisers, merchandisers, etc..). The project architecture should satisfy the operational requirements of the intended subset of the business domain, meaning it should address those relevant roles and their responsibilities in the domain via the capabilities of the interacting (software) components.