Software architecture is all about appropriate compromises. For small projects, having a highly involved software architecture is probably an overkill. For large enterprise applications, it becomes a necessity.
Finding a suitable software architecture for a project requires both technical and domain knowledge: you need to have a solid grasp on the problem your client needs you to solve AND understand the technical trade-offs involved.
Here is a shortlist of architectural virtues to think through when evaluating various architectural patterns and frameworks:
1. System Comprehensibility
Does this architecture enable developers and business owners explain, understand and collaborate well? Does it hide away less-important implementation details and help accurately frame the problem domain?
2. Modularity (Separation of Concerns)
Does this architecture allow for the problem domain to be broken out into smaller, more easily managed parts? Does it promote the healthy isolation of components? Does this allow component reuse and recombination? Does it reduce unnecessary coupling and make dependencies explicit?
3. Testability (Mockable Dependencies)
Does the software architecture facilitate testing at the unit, integration and system level? Does it allow mocking and stubbing of services and infrastructure? Does it allow testing failure modes?
4. Hexagonality (Infrastructure Agnosticism / Domain Isolation)
In this architecture, is possible to isolate the domain (or business) logic from implementation details? Can you segregate and swap out the transport or persistence layer without needing to make major internal changes to the system?
5. Aspect-orientation (Cross-cutting concerns)
Does the architecture allow for uniform, centralized handling of cross-cutting concerns? Can logging, caching, authorization, serialization etc be handled independently from the core logic?
6. Plugin-orientation
Does the architecture allow decoupled and optional processing? Does it allow for integration with external systems as and when needed? Does it offer hooks into it's internal operations without compromising security?
7. Scalability
Does the architecture framework allow for room for growth at least for the foreseeable future? Does it facilitate the measurement and monitoring of system performance?
There are, of course, many more issues to think about... but this is a pretty good set of parameters to think through while making architectural choices.
Top comments (5)
"Software architecture is all about appropriate compromises. For small projects, having a highly involved software architecture is probably an overkill. For large enterprise applications, it becomes a necessity."
I totally agree with you.
Do you recommend any architecture pattern for large enterprise application? How do you think of microservice architecture?
Agreeable. Some time back I thought software architecture is like an ego of personality of the software system. From freud's theory of physiology. courses.lumenlearning.com/boundles...
Is there any book that you would recommend to read about all these principles ?
just released - an overview of topics relevant in software architecture education:
leanpub.com/isaqb-foundation-study...
(disclaimer: I'm one of the authors).
Other great books are from Michael Kealing (Design It!) and Neil Ford (Modern Software Architectures).
Most of these are well-known topics that people have written about in-depth. Unfortunately, I've not come across a book that integrates them all together.