Essential Diagramming Techniques Every Architect Should Master

Mind Map

A mind map (or brain map) is a tree‑shaped, structured‑thinking diagram that starts from a central keyword and expands into categories, helping developers and anyone else to visualize ideas, break down requirements, analyze domain models, and plan technical work.

Example: the author used a mind map to organize the writing logic of this article (see image).

UML Diagrams

Proficiency with UML is a basic skill for architects. Four essential points are emphasized:

Focus on coarse‑grained concerns

Clear business boundaries

Explicit entity relationships

Enumerate variations to avoid missing steps

Although UML includes many diagram types, the author finds four sufficient for daily work: class diagram, sequence diagram, activity diagram, and state diagram.

1. Class Diagram

The author draws two kinds of class diagrams: one for domain‑model design and another for table‑entity relationship design. Domain‑driven design (DDD) is highlighted as a common practice. Table design focuses on field attributes (type, length) and is tightly coupled to the database, while model design emphasizes core attributes, behavior, and relationships, deliberately omitting non‑core fields such as timestamps to reduce cognitive load.

Entity relationships are ordered from strong to weak: Composition > Aggregation > Dependency > Association . In domain modeling the author only uses the two weaker forms—dependency and association—because strong forms can be replaced by a single field (e.g., “receiver address information”). Over‑fine‑grained models lead to maintenance difficulties; using dependency guides subsequent table design.

2. Sequence Diagram

Sequence diagrams analyze complex business flows. Simple CRUD operations usually do not require them. The author stresses “focus on the point of interest” and to draw only the core sequence. Multiple systems result in multiple lifelines; roles are not lifelines and can be shown as small circles indicating entry points. Overly long sequences should be split or organized into horizontal swimlanes to keep them readable.

3. Activity Diagram

Activity diagrams resemble product‑manager flowcharts but operate at a higher granularity than sequence diagrams. They can contain multiple sequences within a single activity and are divided by vertical swimlanes (systems) and horizontal swimlanes (business phases).

4. State Diagram

State diagrams (state machines) depict how an object transitions between stable states, such as order status or procurement status. Two key factors are the current state and the transition conditions that trigger a change.

State: the stable condition of the object.

Transition condition: the series of processes that fire before the state changes.

When designing, avoid enumerating too many states; if necessary, split into multiple state attributes or use separate records. Typically, no more than two state‑related attributes are kept to prevent combinatorial explosion. Complex transition logic is often expressed with a combined state diagram and state table. During implementation, pay attention to the ordering of state changes and apply idempotent handling to prevent concurrency issues.

Architecture Diagram

Architecture diagrams come in many forms—system, network, business, etc.—and must be tailored to the audience. A system architecture diagram abstracts the overall software outline, component relationships, constraints, physical deployment, and evolutionary direction.

Purpose

Eliminate communication barriers.

Reach consensus among stakeholders.

Reduce ambiguity.

Why Draw Them

System diagrams are summaries, not designs; architecture evolves continuously.

They capture a snapshot of the current framework/technology, revealing boundaries that are otherwise invisible.

Creating them is a learning exercise that sharpens thinking about good architectures.

Once the system architecture stabilizes, focus should shift to business architecture to avoid over‑engineering the technical layer.

The author attempted a system architecture diagram in half a day, shared it with the technical director, and received feedback that the e‑commerce framework is typical and that business planning should be the next focus.

Personal Insights

For most projects, developers work on a single system, so applying “big‑component thinking” to guide small‑system development is advisable. Diagramming (mind maps, UML, architecture diagrams) demonstrates design capability, but the core competence remains mastering design patterns, framework philosophies, and service decomposition.

Additional resources for learning UML and architecture diagramming are provided via a personal homepage link (omitted here for brevity).