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:

moduleName
│   module.go (The entry for a Flamingo module)
│   README.md (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