An overview of domains and how domain-specific code is generated using Imagine
Once you write your Imagine config file and use the Imagine compile command in your terminal - Voila! all the relevant files populated with production-ready code are generated as per the settings you have specified.
This Generate code using Imagine section includes:
- an overview of what we mean by domains and how we generate domain-specific-code,
- an overview of writing an Imagine config file, which contains:
- app and domain related settings, as well as
- domain-specific syntax,
- various domains supported by Imagine, where each domain page contains:
- the high level Imagine syntax for the domain functionality we currently support,
- an example of the domain and how it's represented in Imagine syntax,
- Settings supported by Imagine for that domain,
- Imagine's domain-specific-syntax for that domain.
What do we mean by domains?
Domains are functional modules that make up an app
When we talk about
domains, we refer to the functional parts of an app that allow an app to do what is the meant to. Examples of domains would be the:
- the app's
data modelwhich describes how the app's data is organized and related to each other,
storagewhere the app's database and files are stored,
APIwhich defines the kinds of calls or requests that can be made, how to make them, how they are handled, the data formats that should be used, the conventions to follow, etc.,
authorizationdomain, which outlines the types roles that are allowed within an app, and the various permissions that can be granted to different roles,
testingdomain, which includes various types of tests that determine whether various parts of the app are running as they are supposed to,
- and many, many more.
Domains consist of various code modules
Domains consist of code modules which are the highest level representation of concepts pertinent to building that domain. For example:
- the data model domain contains the code modules Model and Relation.
- the API domain contains the code module API.
Domains operate at different levels within an app
Some domains often only reside on the app's backend, other's only on the frontend, and some cut across the frontend and backend (the
Domains are interdependent
Various domains have interdependencies with other domains, e.g.
data modelis one of the basic building blocks of any app.
APIdepends on other domains such as the
- Domains such as
documentationcut across all other domains.
How can you generate domain-specific code using Imagine?
You can generate domain-specific code using Imagine's simple congif file based on the framework/format of your choice
Imagine allows you to express the specifications for each domain in a very simple, intuitive config syntax. It works similar to a shorthand that allows you generate complex functional code with some simple instructions.
Once you've expressed your the specification for your domains in Imagine's config syntax, we can generate code for that domain based on your domain specifications and the framwork / format settings that you have chosen.
For example, the same Imagine API config syntax can be used to generate the code for the API domain using the RestAPI format as well as GraphQL format - just by selecting RestAPI or GraphQL in Imagine API config settings.
Similarly, once we add support for Node in the backend, the same Imagine config for all the backend domains would generate functional code in Node as well as Django just by selecting Node or Django in Imagine app config settings.
Simply select the framework, format and other settings of your choice, and we do the rest.
Code generated using Imagine is fully editable
None of our generated code is 'black box' code. All Imagine generated code is visible to you. You can use and edit this code, as well as integrate with your business logic, as you want.
Code generated using Imagine follows software best practices
Imagine's generated code is high quality and designed to follow software best practices. All our code:
- is production-ready
- is dockerised
- has 100% end-to-end test coverage
- has 100% unit test coverage
- is fully linted
- has automatic logging
- follows standard Git process (incuding Git merge)