Skip to main content

Graphical service design

The graphical service design capability allows users to visually design service projects using an intuitive canvas-based interface. Users can drag and drop various model elements to create comprehensive service architectures and designs.

Overview​

The graphical service design tool provides a visual canvas where you can:

  • Design service architectures using drag-and-drop model elements
  • Organize components by grouping related elements
  • Define relationships between different service components
  • Model complex business logic through visual representations
  • Create integration patterns for external and internal services
❗️info

The graphical service design capability is provided in addition to the existing modelling extensions:

Important: There is no automatic connection between the current modelling capabilities and the new graphical approach. The graphical service design operates independently and does not synchronize with the existing API, domain, or integration models.

Model Elements​

The graphical service design tool offers a comprehensive set of model elements organized into four main categories:

Domain Driven Design​

These elements help you model your business domain following Domain-Driven Design principles:

Aggregate Root​

  • Purpose: Represents the main entity that controls access to a cluster of related objects
  • Usage: Use as the primary entry point for domain operations
  • Characteristics: Maintains consistency boundaries and enforces business rules

Entity​

  • Purpose: Represents objects that have a distinct identity
  • Usage: Model domain objects that are uniquely identifiable
  • Characteristics: Has a unique identifier and lifecycle

Value Object​

  • Purpose: Represents concepts that are defined by their attributes rather than identity
  • Usage: Model immutable objects that describe characteristics
  • Characteristics: Immutable, equality based on values, not identity

Command​

  • Purpose: Represents an intention to change the state of the system
  • Usage: Model user actions or system operations
  • Characteristics: Immutable, represents intent, can be validated

Domain Service​

  • Purpose: Encapsulates domain logic that doesn't naturally fit in entities or value objects
  • Usage: Model complex business operations that span multiple domain objects
  • Characteristics: Stateless, contains domain logic, operates on domain objects

Business Event​

  • Purpose: Represents something significant that has happened in the domain
  • Usage: Model important occurrences that other parts of the system need to know about
  • Characteristics: Immutable, represents past events, can trigger reactions

Business Error​

  • Purpose: Represents domain-specific error conditions
  • Usage: Model business rule violations and exceptional conditions
  • Characteristics: Contains error context, can be handled by business logic

Implementation Design​

These elements help you model the technical implementation of your service:

Class​

  • Purpose: Represents a blueprint for creating objects
  • Usage: Model data structures and behavior in your service
  • Characteristics: Contains properties and methods, defines object structure

Method​

  • Purpose: Represents a function or procedure within a class
  • Usage: Model specific operations and behaviors
  • Characteristics: Has parameters, return type, and implementation logic

Service​

  • Purpose: Represents a collection of related functionality
  • Usage: Model business logic and application services
  • Characteristics: Stateless, provides specific capabilities, can be injected

Integration​

These elements help you model how your service integrates with external systems:

Consumed REST API​

  • Purpose: Represents an external REST API that your service consumes
  • Usage: Model dependencies on external services
  • Characteristics: Defines base URL, authentication, and available operations

Consumed REST Operation​

  • Purpose: Represents a specific operation on a consumed REST API
  • Usage: Model individual API calls to external services
  • Characteristics: HTTP method, endpoint, request/response schemas

Message​

  • Purpose: Represents data structures for asynchronous communication
  • Usage: Model data exchanged between services via messaging
  • Characteristics: Defines message schema, serialization format

Message Listener​

  • Purpose: Represents a component that processes incoming messages
  • Usage: Model asynchronous message processing logic
  • Characteristics: Subscribes to topics, processes messages, handles errors

Message Publisher​

  • Purpose: Represents a component that sends messages
  • Usage: Model asynchronous message sending logic
  • Characteristics: Publishes to topics, handles delivery guarantees

Message Topic​

  • Purpose: Represents a channel for message exchange
  • Usage: Model message routing and distribution
  • Characteristics: Defines message routing rules, delivery semantics

Provided REST API​

  • Purpose: Represents a REST API that your service exposes
  • Usage: Model the external interface of your service
  • Characteristics: Defines base URL, authentication, available operations

Provided API Operation​

  • Purpose: Represents a specific operation in your service's REST API
  • Usage: Model individual endpoints that external clients can call
  • Characteristics: HTTP method, endpoint, request/response schemas

Persistence​

These elements help you model data storage and persistence:

DB Collection​

  • Purpose: Represents a collection of documents in a NoSQL database
  • Usage: Model document-based data storage
  • Characteristics: Schema-less, supports complex nested structures

DB Table​

  • Purpose: Represents a table in a relational database
  • Usage: Model structured data storage with relationships
  • Characteristics: Schema-based, supports ACID transactions, relational integrity