Architecture of a TENUM App
Design Pattern
TENUM® is an opinionated and highly abstract software development system. It therefore has significantly less mental load for human as well as agentic developers.
The fundamental software design principles are:
Domain-Driven Design (DDD): TENUM® uses DDD principles to structure entities in a way that model the business domains. [LEARN MORE]
CQRS (Command Query Responsibility Segregation): The use of CQRS provides a separation between write operations (commands) and read operations (queries). [LEARN MORE]
Event Sourcing: Events are the source of truth in TENUM®. Instead of directly modifying the application state, all changes are recorded as events. This enables TENUM® to recreate the entire state from the recorded events and ensures a clear audit trail for every modification made. [LEARN MORE]
Serverless and Microservice Patterns: Every piece of logic in TENUM®, like message handlers and event handlers, is treated similarly to microservices, allowing the platform to scale functions independently based on load and usage. [LEARN MORE]
Dependency Injection and Factory Pattern: Components, such as UI elements, are created using factory functions. This ensures consistent instantiation of components and the promotion of loose coupling and reusability. [LEARN MORE]
FrontEnd Design Pattern: We have built LuAct, an React-like approach to UI development. LuAct is a core component of TENUM®'s architecture, inspired by React, and it is designed to help build user interfaces using Lua. It provides a set of tools and patterns that are similar to React, allowing you to create dynamic, stateful components in an intuitive way.
UI Libraries: apart from building your own UI components you can use Chakra UI as well as other already integrated UI libraries such as [name]
Based on this Design Pattern all you need to do in TENUM® is to write Artifacts [TT] i.e. the software components that match this design pattern.
What is an Artifact in TENUM®?
In TENUM®, an artifact is simply a specialized code file that solves a particular piece of your app or project. Such as an UI component, an entity (with commands/events), a message handler, or even a testing script.
Each project (application/library/microservice) in TENUM® is built using these artifacts, each with its own filetype.
All artifacts (FrontEnd and BackEnd) are written in Lua. Even the FrontEnd - with a React-like Lua variant - LuAct.
By defining your logic in these artifacts, you automatically plug into TENUM® ’s core features, such as real-time data syncing, testing, or serverless deployment. This means you don’t have to deal with the usual setup or plumbing. TENUM® handles all the behind-the-scenes work, so you can stay focused on building your application’s actual functionality.
Also, advanced users can create their own artifacts in TENUM®.
Artifacts Overview and Naming Convention
Below a list of all currently available artifacts in TENUM®.
A login.uie.luafile may contain a login “UI element”, a getToDo.mh.lua file e.g. a message handler to retrieve a "ToDo" object i.e. message handlers are your endpoints and so forth.
The set of these files in your project compose the architecture of your application/library.
More artifacts are planned and are coming soon [LINK].
Complex Systems
For larger, non-trivial systems, you can also decouple them into multiple applications and libraries and link them, i.e. build your project using a microservice architecture
In TENUM®, microservices are naturally supported. Each microservice can be implemented as a set of artifacts—with entities managing domain data and logic, message handlers serving as HTTP-accessible endpoints, and event handlers enabling asynchronous communication between services.
Because TENUM® artifacts are inherently modular and isolated, you can develop independent services that interact through well-defined APIs or shared event streams. And TENUM® ’s built-in scalability ensures each microservice scales independently.
File Structure
For our very simple sample ToDo app the file structure looks like this:
A folder in the root directory in the project file structure represents a specific feature or domain of the application.
For this simple todo app all you would have to do is write the code and you are done. It has concurrency, it scales, it is deployed and available under a unique TENUM® domain, you have a test environment, a Kanban board to discus further changes with e.g. a business owner etc.
Namespaces
Artifacts are grouped under namespaces based on their module or feature.
Example: The Todo module above use the namespace todo.api for entities and handlers and todo.uifor UI elements.
Special Focus: initial.uie.lua
The initial.uie.lua file serves as the entry point for the TENUM® application. It defines the initial UI layout and component rendering logic, acting as the bridge between the application’s UI and backend artifacts.
By defining the layout and linking other UI components, the initial.uie.lua controls how users initially experience your app. Essentially, it’s both your “home page” and the conductor that wires up all your front-end pieces without you having to manage the underlying page load or routing details.
It’s written as a UI artifact (hence the .uie.lua extension), meaning it hooks directly into TENUM® ’s rendering system and can use LuAct (TENUM® ’s React-like framework) and routing features.
The initial.uie.lua file typically includes:
Imports: Dependencies such as session management, UI factories, and components. ADD TDM HERE
Router Setup: Defines routes and renders the corresponding UI components.
Main Component: The root UI component that encompasses the app’s layout and navigation.
Special Focus: package.json
Much like a traditional package file, the TENUM® package.json serves as a central manifest for your project’s dependencies—but instead of pointing to npm packages, it references TENUM® artifacts** or modules from TENUM® ’s ecosystem.
By listing each artifact (with its group and version), you let TENUM® know exactly what to fetch, link, and deploy alongside your code. This way, you don’t have to manually manage or bundle external libraries—TENUM® does it automatically for you, keeping your setup simple and your app consistently in sync with the artifacts you rely on.
This file is therefore essential for defining libraries and services that the application relies on.
Currently available Dependencies in TENUM® can be browsed and added through the TENUM® Dependency Manager (TDM)** [Link].