Skip to content
This repository was archived by the owner on Mar 4, 2026. It is now read-only.

DEVELOPER.md

Latest commit

 

History

History
164 lines (115 loc) · 4.7 KB

DEVELOPER.md

File metadata and controls

164 lines (115 loc) · 4.7 KB

Alba server developer guide

Architecture

The project uses a 2-dimensional module structure, where the top-level modules are context-based, and the submodules are a simplification of the modules often used in Domain-driven Design.

Context modules

The top-level context modules represent logic components and constitutes bounded contexts, e.g. Rundown Execution, Action System, iNews Ingest and Asset Management. The context modules at the moment are:

graph TD

rundownExecution[["
  Rundown Execution
  [Context Module]

  Manages rundown state.
"]]

rundownIngest[["
  Rundown Ingest
  [Context Module]

  Handles rundown ingest workflow independent
  of which ingest gateway is used.
"]]

tv2InewsIngest[["
  TV 2 iNews Ingest
  [Context Module]

  Manages iNews Gateway connections and mapping
  TV 2-specific iNews syntax into Albas ingest-format.
"]]

sofieIngest[["
  Sofie Ingest
  [[Context Module]]

  Manages integration to the Sofie database.
  It is isolated as these will be phased out step-by-step.
"]]

blueprints[["
  Blueprints
  [[Context Module]]

  Manages rundown creation from external data.  
"]]

actionSystem["
  Action System
  [Context Module]

  Manages applicable user actions.
"]

crossCuttingConcerns[["
  Cross-cutting Concerns
  [Context Module]

  Holds shared logic and types that are used by almost all other modules. 
"]]

tv2InewsIngest --> |"provides rundown ingest changes to"| rundownIngest
rundownIngest -.-> |"synchronizes rundown changes to"| rundownExecution
sofieIngest --> |"synchronizes sofie changes to"| rundownExecution
sofieIngest --> |"transforms Sofie data to Alba data with"| blueprints
rundownIngest -.-> |"builds rundown data with"| blueprints
actionSystem --> |"runs user actions against"| rundownExecution
Loading

Submodules

The Domain-driven Design-based submodules are:

graph TD


domain["
  Domain
  [Submodule]

  Contains domain rules and logic.
"]

application["
  Application
  [Submodule]

  Contains use case logic.
"]

infrastructure["
  Infrastructure
  [Submodule]

  Technical capability and framework integrations.
"]

application --> |"may depend on"| domain
infrastructure --> |"may depend on interfaces from"| domain
infrastructure --> |"may depend on interfaces from"| application
Loading

Domain

The domain submodule contains structures like:

  • Entities
  • Value objects
  • Aggregates
  • Domain services
  • Domain events
  • Repository interfaces

Warning

It is worth noting that the repository interfaces are defined in the domain layer, but not used. The reason for doing it this way is that the repository can exhibit domain rules through intent. An example could in a gaming system, a given set of use cases that specialises with gambling, require the users to be adults as they per law can’t have minors engaging in gambling. So instead of having the domain rule scattered out in the use cases, the repository for users could expose a method for only getting adult users. For quick reference: Repositories are defined in the domain layer, implemented in infrastructure layer and used in the application layer.

Application

The application submodule contains structures like:

  • Use case services
  • DTOs and DTO mappers
  • Port interfaces (e.g. HttpServer, EmailSender)
  • Controllers
  • Input validation

Infrastructure

The infrastructure submodule contains structures like:

  • Repository implementations.
  • External service integrations (HttpServer, MailSender, HttpRequestService, Database, Logging).
  • Application configuration management.

Module interaction

Contracts is used as a term for exposed structures, which can be interfaces, facades, services or the like. Intra-module dependencies:

From \ To Domain Application Infrastructure
Domain Everything
Application Contracts Everything
Infrastructure Contracts Contracts Everything

Inter-module dependencies:

From \ To External Domain External Application External Infrastructure
Domain Contracts
Application Contracts
Infrastructure Contracts

All inter-module dependencies should be used with caution.

The Cross-cutting Concerns module may not depend on any other module and the allowed dependencies on the Cross-cutting Concerns module is more relaxed than what is described in the table above.