What is Service Architect?

When to use

Start here to understand the product, its model and the relationship between the designer, generated code and ServiceLib runtimes.

Behavior

• Design the system as a graph of services, streams, links, connectors, endpoints, types, pools and modules.
• Use the topology as the shared contract consumed by the visual designer, code generator and runtime libraries.
• Generate complete projects for supported target languages instead of manually wiring transports and stream execution.
• Implement business logic in generated extension points while the framework owns infrastructure and graph execution.
• Keep architecture and implementation aligned: the graph that documents the system is also the graph used to generate and run it.

Architecture that runs

Service Architect treats architecture as executable input rather than a diagram maintained separately from the code. The visual graph is the source of truth for service boundaries, data flow, integrations and runtime execution.

A useful mental model is React for distributed backend systems: you describe the structure and relationships, the framework wires the infrastructure, and application developers focus on business behavior.

How the product works

The same topology passes through the complete development workflow.

• Model services and typed data flows in the visual designer.
• Configure connectors and their endpoints for external systems.
• Choose stream operators and execution properties for processing pipelines.
• Generate target-language projects and runtime wiring.
• Implement business functions in the generated extension points.
• Run services with observability that follows the topology.

Product components

The product is composed of cooperating layers rather than a standalone diagram editor.

• Visual designer: creates and edits the service topology.
• Topology model and API: define services, streams, links, types, connectors, endpoints, pools and modules.
• servicegen: validates the model and generates target-language projects.
• ServiceLib runtimes: execute streams, transports, scheduling and framework integrations.
• Generated stubs: stable extension points where application code implements business logic.

What is generated

Depending on the selected language and integrations, generated projects include service structure, stream wiring, transport adapters, serialization contracts, concurrency setup, error propagation and business-logic interfaces.

The generator removes repetitive infrastructure work without hiding the architecture: each generated component remains traceable to an element in the topology.

Topology-aware observability

Tracing and metrics follow the graph, so operational data can be understood in architectural terms. Stream execution, connector calls and service boundaries retain their identity from design through runtime.

Configuration example

1. Define data types and services.
2. Draw stream pipelines and links.
3. Add connectors and endpoints.
4. Select target-language implementations.
5. Generate projects and implement business functions.

Related documentation