Skip to content

Flamingo Module Structure

Module structure

Modules that contain business logic of some kind should:

  • by itself responsible for a clear concern / bounded context
  • have as less as possible dependencies to other modules
  • implement ports and adapters and therefore follow the naming and structure conventions.

For a quick reference:

│   module.go (The entry for a Flamingo module)
│ (The full documentation)
└───domain (technology free domain logic with secondary ports)      
└───application (main modules use cases / programmers "API")
└───interfaces (interfaces to the outside)
│   └───controller (web and data controllers)
│   └───templatefunctions (templatefunctions)
└───infrastructure (implementation of secondary ports)
│   └───adapterExample.go (e.g. an adapter to an external microservice)

For more read Ports and Adapters Architecture

Flamingo Module initialisation

Each Flamingo module should have a module.go in the root folder.

Here you typically:

  • provide the Module Type with its Configure method as an entry to configure your module
  • use Dingo (dependency injection) for Binding your types.
  • register Routes and Handlers
  • provide Default Configurations
  • register Flamingo Commands, template functions and event listeners