Detailed Classification of Architecture Diagrams
Process Type
Graphical expression
Mind Type
Structured expression
Note Type
Efficient expression
Treemap
Bracket Diagram
Default Mode
Supports real-time multi-user co-creation with shareable links for instant information transfer
Automatically generates graphics from text input and applies style enhancements
Prebuilt themes with full customization for personalized designs
Supports icons, images, labels, LaTeX formulas, code blocks, links, attachments and more
Export: PNG, VISIO, PDF, SVG | Import: VISIO, Mermaid
Real-time cloud storage, multi-device sync, version history, and secure data protection
Application architecture only concerns itself with which application systems and platforms are needed to meet business goals, without considering which technologies need to be used throughout the construction process. Technical architecture, on the other hand, addresses the technical requirements derived from application architecture and involves selecting technologies and clarifying the relationships between various key technologies.
Yes. A microservices architecture diagram is a specific type of technical architecture diagram that specifically shows how to decompose a system into independent, deployable microservices. Simply put, a microservices architecture diagram is the application of a technical architecture diagram in a microservices context.
The product architecture diagram serves as the foundation for guiding the technical architecture diagram. Therefore, the sequence of drawing technical and product architecture diagrams is usually to have the product architecture diagram first, followed by the technical architecture diagram. The product architecture diagram focuses on the product's functions, modules, and user interactions, while the technical architecture diagram focuses on the specific technical solutions, system components, and interaction methods needed to implement these functions.
The technical architecture diagram encompasses four dimensions: hardware architecture, software architecture, middleware architecture, and data architecture. It not only visually presents system modules, components, and their dependencies but also provides a structured view throughout the entire cycle of requirements analysis, architecture design, and deployment maintenance, ensuring consistent understanding of system design within the team.
It must be reflected. The diagram should clearly indicate system exposure boundaries, firewalls, WAF, security domains, SSO, access control, etc., otherwise, the diagram has no reference value during security reviews.
Yes. It is recommended to note the frameworks (such as SpringBoot, Kafka), languages (such as Java, Python), databases (such as MySQL, MongoDB), etc., used in key components. This is helpful for development, operations, technology selection, and troubleshooting.
The direction of arrow calls should be clearly drawn, and the communication method (such as REST, gRPC, MQ, WebSocket) should be noted next to the arrows. Otherwise, the information in the diagram is difficult to understand accurately, especially when designing interfaces and analyzing performance.
Yes, it is recommended to use a 'system governance layer' or 'operations platform layer' to display these components, such as Jenkins, Prometheus, ELK, SkyWalking, etc.
