{"id":1398,"date":"2026-02-25T10:40:52","date_gmt":"2026-02-25T10:40:52","guid":{"rendered":"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/"},"modified":"2026-02-25T10:40:52","modified_gmt":"2026-02-25T10:40:52","slug":"uml-class-diagrams-that-scale","status":"publish","type":"docs","link":"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/","title":{"rendered":"Class Diagrams That Scale: Designing Logical Structures"},"content":{"rendered":"

When you’re designing a system that must evolve across teams, versions, and years, the real test isn\u2019t just whether your class diagram is correct\u2014it\u2019s whether it stays useful. I\u2019ve seen teams waste months on diagrams that looked elegant but collapsed under minor changes. The breakthrough came when I stopped chasing textbook perfection and started focusing on scalability. The key insight? A good class diagram isn\u2019t about every detail\u2014it\u2019s about intentional abstraction.<\/p>\n

Here, you\u2019ll learn how to build UML class diagrams that don\u2019t just model a system\u2014they endure it. You\u2019ll grasp how to structure entities, manage UML class relationships, and apply object modeling principles that scale with real engineering complexity.<\/p>\n

Over the past two decades, I\u2019ve worked with architects across finance, healthcare, and logistics\u2014each with different constraints, constraints that revealed a truth: scalable design isn\u2019t about more layers, it\u2019s about better ones.<\/p>\n

Foundations of Scalable Object Modeling<\/h2>\n

Start with the Right Abstraction Level<\/h3>\n

Abstraction is the first filter in object modeling. Too coarse, and you lose critical behavior. Too fine, and the diagram becomes a maintenance nightmare.<\/p>\n

Ask yourself: what do developers need to understand to use this system? Not every method. Not every state. The core entities, their responsibilities, and how they connect.<\/p>\n

Think of abstraction as a lens. You\u2019re not showing everything. You\u2019re showing what matters for the current purpose\u2014whether it\u2019s integration, deployment, or requirement validation.<\/p>\n

Decide What to Model\u2014And What to Leave Out<\/h3>\n

Not every class needs to appear. In a healthcare system, Patient and Appointment are essential. But a class like MedicalRecordsStorageEngine? Probably not. It\u2019s implementation detail.<\/p>\n

Use the \u201cWho needs this?\u201d test: if a developer wouldn\u2019t need to know this class to perform their role, it likely doesn\u2019t belong in the core UML class diagram.<\/p>\n

Be ruthless. A clean diagram isn\u2019t one with fewer boxes\u2014it\u2019s one with only the right ones.<\/p>\n

Mastering UML Class Relationships<\/h2>\n

Associations: The Backbone of Design Clarity<\/h3>\n

Associations define how classes interact. They\u2019re not just lines\u2014they\u2019re promises of responsibility.<\/p>\n

Don\u2019t default to an unidirectional arrow. Ask: who owns the relationship? Is it a user managing orders, or an order pointing to a user? Ownership tells you who\u2019s responsible for maintaining the link.<\/p>\n

Use navigable associations where appropriate. If a Customer class needs to access all their Orders, make the association directional from Customer to Order. This prevents unnecessary traversal.<\/p>\n

Aggregation vs. Composition: The Difference That Matters<\/h3>\n

Aggregation is \u201chas-a.\u201d Composition is \u201cowns-a.\u201d The distinction isn\u2019t semantic\u2014it\u2019s about lifecycle.<\/p>\n

A composition<\/strong> relationship means the child object cannot survive independently. If the parent is deleted, the child is too. A House has Rooms\u2014when the house is torn down, the rooms disappear.<\/p>\n

A aggregation<\/strong> means the child can exist separately. A University has Professors\u2014professors can move to another school.<\/p>\n

Use composition when the lifecycle is tied. Use aggregation when it\u2019s not. Misapplying this leads to memory leaks and inconsistent state.<\/p>\n

Dependency: The Invisible Link<\/h3>\n

Dependency is the weakest relationship, but often the most useful. It means one class uses another briefly.<\/p>\n

Example: a PaymentProcessor that uses a DateHelper class only during validation. This is not ownership. It\u2019s temporary use.<\/p>\n

Use dependency for utilities, services, or short-lived operations. It keeps your diagram clean and signals non-essential coupling.<\/p>\n

Designing for Scale: Practical Patterns<\/h2>\n

Use Inheritance with Caution<\/h3>\n

Inheritance is powerful, but it\u2019s also one of the most abused UML class relationships.<\/p>\n

Ask: is this a \u201cis-a\u201d relationship? If not, reconsider. A Car is a Vehicle. A Sedan is a Car. But a Car has a GPS\u2014this isn\u2019t inheritance. It\u2019s composition.<\/p>\n

Overuse of inheritance makes your system brittle. Changes to a parent class ripple through everything. Prefer composition for flexibility.<\/p>\n

Apply the Interface Segregation Principle (ISP)<\/h3>\n

Don\u2019t bundle every behavior into one giant interface. Split responsibilities.<\/p>\n

In a banking system, you might have:<\/p>\n

    \n
  • Transferable<\/code> \u2013 for sending money<\/li>\n
  • Authenticatable<\/code> \u2013 for login and verification<\/li>\n
  • Reportable<\/code> \u2013 for generating statements<\/li>\n<\/ul>\n

    Each interface has one clear purpose. Classes implement only what they need. This reduces coupling and strengthens modularity.<\/p>\n

    Leverage Package Diagrams for Logical Grouping<\/h3>\n

    Even in a single class diagram, you can\u2019t list every class. That\u2019s where package diagrams come in.<\/p>\n

    Group classes by domain: domain.model<\/code>, infrastructure.repository<\/code>, application.service<\/code>.<\/p>\n

    Use a table to map responsibilities:<\/p>\n\n\n\n\n\n\n
    Package<\/th>\nResponsibility<\/th>\nKey Classes<\/th>\n<\/tr>\n
    domain.model<\/code><\/td>\nBusiness logic and entities<\/td>\nCustomer, Order, Invoice<\/td>\n<\/tr>\n
    infrastructure.repository<\/code><\/td>\nData persistence and access<\/td>\nCustomerRepository, OrderMapper<\/td>\n<\/tr>\n
    application.service<\/code><\/td>\nUse case execution and orchestration<\/td>\nOrderService, PaymentProcessor<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    These packages are not just organizational\u2014they\u2019re blueprints for scalable architecture.<\/p>\n

    Improving Readability and Maintainability<\/h2>\n

    Apply Consistent Naming and Notation<\/h3>\n

    Use clear, consistent naming. CustomerService<\/code> is better than CustomerMgr<\/code> or CSvc<\/code>. Use camelCase or PascalCase based on your team\u2019s convention.<\/p>\n

    Be consistent with notation:<\/p>\n

      \n
    • Always use +<\/code> for public, -<\/code> for private, #<\/code> for protected.<\/li>\n
    • Always show multiplicity. 1..* <\/code> is clearer than just \u201cmany\u201d.<\/li>\n
    • Use meaningful association names: placesOrder<\/code>, hasPayment<\/code>, not assoc1<\/code>.<\/li>\n<\/ul>\n

      Use Constraints and Stereotypes Sparingly<\/h3>\n

      Stereotypes like \u00abentity\u00bb, \u00abusecase\u00bb, \u00abboundary\u00bb are helpful in larger models. But don\u2019t overuse them.<\/p>\n

      They become noise when every class wears a label. Use them only when they add clarity\u2014like marking a class as \u00abaggregate root\u00bb or \u00abvalue object\u00bb in domain-driven design.<\/p>\n

      Keep It Simple, Even When the System Is Not<\/h3>\n

      Scale doesn\u2019t mean complexity. It means clarity under pressure.<\/p>\n

      When in doubt, simplify. Merge related concepts. Remove redundant associations. Revert to a higher-level abstraction.<\/p>\n

      Remember: the goal is not to model every detail. It\u2019s to create a shared understanding. A good diagram is readable in 30 seconds.<\/p>\n

      Frequently Asked Questions<\/h2>\n

      How do I decide when to use inheritance in UML class diagrams?<\/h3>\n

      Use inheritance only when you have a true \u201cis-a\u201d relationship. Ask: can the subclass be substituted for the superclass without breaking behavior? If yes, inheritance is valid. If not, prefer composition.<\/p>\n

      What\u2019s the best way to avoid overloading a class diagram?<\/h3>\n

      Group classes into packages. Limit the number of classes per diagram. Use high-level views for architecture and detailed diagrams for components. Keep each diagram focused on a single concern.<\/p>\n

      Why is multiplicity important in UML class relationships?<\/h3>\n

      Multiplicity defines the cardinality of a relationship\u2014how many instances of one class relate to another. It prevents runtime errors by clarifying how data flows. For example, an Order must have exactly one Customer, but a Customer can have many Orders.<\/p>\n

      How do I model a many-to-many relationship in UML class diagrams?<\/h3>\n

      Use an association class. For example, a Student takes Courses. Instead of a direct link, create an intermediate class like Enrollment<\/code> with attributes like enrollmentDate<\/code> and grade<\/code>. This captures the relationship\u2019s behavior.<\/p>\n

      When should I use aggregation over composition?<\/h3>\n

      Use composition when the child object depends on the parent for existence. Use aggregation when the child can exist independently. A House has Rooms (composition), but a University has Professors (aggregation).<\/p>\n

      Can object modeling and UML class diagrams be automated?<\/h3>\n

      Yes\u2014tools like Visual Paradigm support reverse engineering from code and forward engineering to code. But automation doesn\u2019t replace good design. It amplifies it. Always validate generated diagrams for correctness and clarity.<\/p>\n","protected":false},"excerpt":{"rendered":"

      When you’re designing a system that must evolve across teams, versions, and years, the real test isn\u2019t just whether your class diagram is correct\u2014it\u2019s whether it stays useful. I\u2019ve seen teams waste months on diagrams that looked elegant but collapsed under minor changes. The breakthrough came when I stopped chasing textbook perfection and started focusing […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":1397,"menu_order":0,"template":"","meta":{"_acf_changed":false,"inline_featured_image":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"doc_tag":[],"class_list":["post-1398","docs","type-docs","status-publish","hentry"],"acf":[],"yoast_head":"\nUML Class Diagrams That Scale<\/title>\n<meta name=\"description\" content=\"Master scalable UML class diagrams for large systems. Learn object modeling, UML class relationships, and design patterns that work in real-world software development.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/\" \/>\n<meta property=\"og:locale\" content=\"vi_VN\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"UML Class Diagrams That Scale\" \/>\n<meta property=\"og:description\" content=\"Master scalable UML class diagrams for large systems. Learn object modeling, UML class relationships, and design patterns that work in real-world software development.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/\" \/>\n<meta property=\"og:site_name\" content=\"Visual Paradigm Skills Ti\u1ebfng Vi\u1ec7t\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"\u01af\u1edbc t\u00ednh th\u1eddi gian \u0111\u1ecdc\" \/>\n\t<meta name=\"twitter:data1\" content=\"6 ph\u00fat\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/\",\"url\":\"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/\",\"name\":\"UML Class Diagrams That Scale\",\"isPartOf\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/vn\/#website\"},\"datePublished\":\"2026-02-25T10:40:52+00:00\",\"description\":\"Master scalable UML class diagrams for large systems. Learn object modeling, UML class relationships, and design patterns that work in real-world software development.\",\"breadcrumb\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/#breadcrumb\"},\"inLanguage\":\"vi\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/skills.visual-paradigm.com\/vn\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Real-World UML: Case Studies in Software Design\",\"item\":\"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Core Modeling Disciplines\",\"item\":\"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/\"},{\"@type\":\"ListItem\",\"position\":4,\"name\":\"Class Diagrams That Scale: Designing Logical Structures\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/vn\/#website\",\"url\":\"https:\/\/skills.visual-paradigm.com\/vn\/\",\"name\":\"Visual Paradigm Skills Ti\u1ebfng Vi\u1ec7t\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/vn\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/skills.visual-paradigm.com\/vn\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"vi\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/vn\/#organization\",\"name\":\"Visual Paradigm Skills Ti\u1ebfng Vi\u1ec7t\",\"url\":\"https:\/\/skills.visual-paradigm.com\/vn\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"vi\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/vn\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/skills.visual-paradigm.com\/vn\/wp-content\/uploads\/sites\/11\/2026\/02\/favicon.svg\",\"contentUrl\":\"https:\/\/skills.visual-paradigm.com\/vn\/wp-content\/uploads\/sites\/11\/2026\/02\/favicon.svg\",\"width\":70,\"height\":70,\"caption\":\"Visual Paradigm Skills Ti\u1ebfng Vi\u1ec7t\"},\"image\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/vn\/#\/schema\/logo\/image\/\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"UML Class Diagrams That Scale","description":"Master scalable UML class diagrams for large systems. Learn object modeling, UML class relationships, and design patterns that work in real-world software development.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/","og_locale":"vi_VN","og_type":"article","og_title":"UML Class Diagrams That Scale","og_description":"Master scalable UML class diagrams for large systems. Learn object modeling, UML class relationships, and design patterns that work in real-world software development.","og_url":"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/","og_site_name":"Visual Paradigm Skills Ti\u1ebfng Vi\u1ec7t","twitter_card":"summary_large_image","twitter_misc":{"\u01af\u1edbc t\u00ednh th\u1eddi gian \u0111\u1ecdc":"6 ph\u00fat"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/","url":"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/","name":"UML Class Diagrams That Scale","isPartOf":{"@id":"https:\/\/skills.visual-paradigm.com\/vn\/#website"},"datePublished":"2026-02-25T10:40:52+00:00","description":"Master scalable UML class diagrams for large systems. Learn object modeling, UML class relationships, and design patterns that work in real-world software development.","breadcrumb":{"@id":"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/#breadcrumb"},"inLanguage":"vi","potentialAction":[{"@type":"ReadAction","target":["https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/uml-class-diagrams-that-scale\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/skills.visual-paradigm.com\/vn\/"},{"@type":"ListItem","position":2,"name":"Real-World UML: Case Studies in Software Design","item":"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/"},{"@type":"ListItem","position":3,"name":"Core Modeling Disciplines","item":"https:\/\/skills.visual-paradigm.com\/vn\/docs\/real-world-uml-case-studies-software-design\/core-modeling-disciplines\/"},{"@type":"ListItem","position":4,"name":"Class Diagrams That Scale: Designing Logical Structures"}]},{"@type":"WebSite","@id":"https:\/\/skills.visual-paradigm.com\/vn\/#website","url":"https:\/\/skills.visual-paradigm.com\/vn\/","name":"Visual Paradigm Skills Ti\u1ebfng Vi\u1ec7t","description":"","publisher":{"@id":"https:\/\/skills.visual-paradigm.com\/vn\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/skills.visual-paradigm.com\/vn\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"vi"},{"@type":"Organization","@id":"https:\/\/skills.visual-paradigm.com\/vn\/#organization","name":"Visual Paradigm Skills Ti\u1ebfng Vi\u1ec7t","url":"https:\/\/skills.visual-paradigm.com\/vn\/","logo":{"@type":"ImageObject","inLanguage":"vi","@id":"https:\/\/skills.visual-paradigm.com\/vn\/#\/schema\/logo\/image\/","url":"https:\/\/skills.visual-paradigm.com\/vn\/wp-content\/uploads\/sites\/11\/2026\/02\/favicon.svg","contentUrl":"https:\/\/skills.visual-paradigm.com\/vn\/wp-content\/uploads\/sites\/11\/2026\/02\/favicon.svg","width":70,"height":70,"caption":"Visual Paradigm Skills Ti\u1ebfng Vi\u1ec7t"},"image":{"@id":"https:\/\/skills.visual-paradigm.com\/vn\/#\/schema\/logo\/image\/"}}]}},"_links":{"self":[{"href":"https:\/\/skills.visual-paradigm.com\/vn\/wp-json\/wp\/v2\/docs\/1398","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/skills.visual-paradigm.com\/vn\/wp-json\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/skills.visual-paradigm.com\/vn\/wp-json\/wp\/v2\/types\/docs"}],"author":[{"embeddable":true,"href":"https:\/\/skills.visual-paradigm.com\/vn\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":0,"href":"https:\/\/skills.visual-paradigm.com\/vn\/wp-json\/wp\/v2\/docs\/1398\/revisions"}],"up":[{"embeddable":true,"href":"https:\/\/skills.visual-paradigm.com\/vn\/wp-json\/wp\/v2\/docs\/1397"}],"wp:attachment":[{"href":"https:\/\/skills.visual-paradigm.com\/vn\/wp-json\/wp\/v2\/media?parent=1398"}],"wp:term":[{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/skills.visual-paradigm.com\/vn\/wp-json\/wp\/v2\/doc_tag?post=1398"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}