Differentiate the base app and the system app
AL developers can extend the functionality of Business Central in several ways. They can extend tables, enumerations, application areas, pages, reports, code flows, and the security model. They can also contribute directly to the base application in the open source projects for the system application modules.
The Business Central application consists of multiple layers:
System Application: This is a set of open source modules that make it easier to build, maintain, and easily upgrade on-premises and online apps. These modules let you focus on the business logic, and the needs of your users or customers.
Base Application: This is the business logic for the functionality in Business Central.
Overview of the System Application
The System Application contains modules that interact with the Dynamics 365 Business Central platform and online ecosystem to support the business logic in the Base Application. If you are developing extensions or add-ons for Dynamics 365 Business Central, you'll probably need to use one or more of the objects in the modules.
For an overview of the modules in the System Application, see Overview of the modules in the System Application.
System and Base Application Reference for Dynamics 365 Business Central
In the System Application section, you can find an overview of all the objects that make up the system application layer in Business Central, including obsoleted objects sorted by object type. In the Base Application section, you can find an overview of all the objects that make up the base application layer in Business Central. This also includes a section of obsoleted objects, sorted by object type.
For more information, see System and Base Application Reference for Dynamics 365 Business Central.
Module architecture
Though the internal architecture of modules can, and most likely will, differ, there are rules that ensure consistency and reliability in the architecture of application modules. To reduce coupling and increase consistency, every module is a separate entity that has a publicly accessible facade, while the internal implementation isn't public, as shown in the following image.
Modules are independent projects and have their own app.json files.
Modules can belong to a specific package, or functional layer. A module becomes part of a layer when it’s added to the folder structure of the layer’s package. A module can belong to several packages because the module is a package of its own, and can be bundled into larger functional layering packages.
Dependencies to other modules can only be taken to modules in the same functional layer or to lower layers. For example, a module in the Core Application can only take dependencies to modules in the Core Application or System Application, but never to extensions.
Every module must initially target the most restrictive environment, which is the cloud environment. If unsafe operations are required, those should result in a System Application module where the unsafe operations are wrapped with safe APIs. That is done by setting the Target to OnPrem. Modules in layers above the System Application must have Target set to Cloud in the app.json file.
Only facade codeunits, pages, and tables required in the public API of the module can be accessible. Internal implementation details must be marked as such by setting the access modifier to Internal. For example, entities can be accessed within the module but can't be called from outside the module.
Every module must have a facade that meets the following rules:
Access must be Public. It should be set explicitly to emphasize that this is a facade or an API-like codeunit that exposes the core functionality in the module.
All integration and business event publishers must be in the facade as internal functions. This prevents them from being invoked outside the module.
Event publishers should be marked as internal. Exceptions must be documented.
All external methods go in the facade.
Facades can't contain logic or local functions.
Because the facade is the codeunit that other modules reference, it should have a short, meaningful name. Internal implementation codeunits can be suffixed with Impl, for example, because they aren't referenced outside the module.
Implementation codeunits contain business logic. Pages and tables can contain code but should do so only when it's absolutely required.
Extensibility must be thought into the internal implementation of every module. If a module shouldn't be extensible, the Extensibility property on tables, pages, and enums must be set to False to prevent those objects from being extended.
Here are some options where you can find documentation about how you can develop modules:
If you want to contribute code to the Business Central open source System Application, you need to determine the type of contribution:
Small bug fixes, product improvements, or customer conveniences
New capabilities or larger changes to the existing application platform
For more information about making contributions, go to Contributing to the Business Central open source System Application.
To learn more about the System Application, its module architecture, and how to modify or create new modules, go to Module Architecture.