01Application composition
Actions are your application contract
Define a named operation with validation, policy, resilience, transaction, audit, history, quota, and observability hooks. Keep the business capability independent of how it reaches the system.
02Service boundaries
Attach the transport that fits
Expose application actions through HTTP, NATS, cron, and worker transports. The same capability can serve an API, an event subscriber, a background job, or a scheduled operation.
03System building blocks
Build multi-tenant systems deliberately
Use tenant-aware authorization, roles, features, encryption, audit chains, transactional persistence, domain events, and operational tooling as reusable architecture components.
Proof by source
Named actions. Transport boundaries. System context.
These compact examples show the engineering assets behind our service work: compose business capabilities, attach the delivery mechanism, and keep policy, tenancy, data, events, and operational context alongside the application action.
app := nexss.New("billing")
app.Use(createInvoice, settleInvoice)
app.HTTP(":8080", createInvoice)
app.NATS(natsURL, settleInvoice)
System composition by design
Use technical foundations to reduce delivery risk—not to constrain the client.
We can use the Framework when one named capability must serve an HTTP endpoint, a NATS subscription, a scheduled operation, or a worker process. Where another approach is better, we choose that instead.
Next evidence
Keep service logic close to the system that needs to evolve.
Use the source as technical evidence, then bring us the architecture or delivery problem you need to solve.