Flamingo 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
Configuremethod 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