Disclosure: I build Schemity, a desktop ERD tool - this post is from our blog and uses it for the examples.
TL;DR: Relational databases cannot store a many-to-many relationship directly, so most ERD tools make you hand-build the junction table - Microsoft documents six manual steps for one relationship. In Schemity, you drag between the two entities and pick N:N; the junction table appears with its foreign keys, composite primary key, and convention-following name already in place, as a real table you can rename and extend. One refinement: keep that composite primary key when both parents live in the same bounded context, but give a junction its own id plus a unique constraint over the pair when it bridges two contexts or grows a lifecycle of its own, like a subscription - so the pairing can recur and the contexts can split databases later without rewriting the table's identity.
A many-to-many relationship is one conceptual fact, and expressing one fact in your diagram should cost one gesture - not a hand-assembled third table with copied key columns and two carefully aimed relationship lines. The junction table is a mechanical consequence of the relationship, and mechanical consequences are exactly what a tool should produce for you.
