Dynamics 365 FO - Model Driven architecture

Dynamics 365 FO - Model Driven Architecture

Nghia Song - Microsoft Dynamics 365 Technical Consultant

Nghia Song
Tel - WhatsApp: +84967324794
Email: songnghia.uit@gmail.com

Model Driven architecture

Microsoft Dynamics 365 is designed with a unique layer and model structure that separates and controls the updates and modifications made in the application. This structure provides a powerful and flexible architecture for developing business logic.

Layers

Layers are a hierarchy of levels in the application you can use to make modifications and additions without interfering with the application elements in the next lower level. When you make an element modification on one level, the modification overshadows the element on a lower level. When the application is compiled, only the top-level version of an application element is used.

There are three layers available only to Microsoft to deliver the base application.

(The xxP layer indicates the patch layer for each application object layer).

There are three layers available to partners and ISVs.

There are two layers available to both partners and customers who have a license to access the 365 source code.

Benefits of Layers: Source Code Protection

The elements in the standard implementation (SYS, GLS, FPK layers) can only be changed or deleted by the Microsoft Dynamics D365 Development team.

The layers help protect the original source code and keep it separate from modifications. Similarly, ISV solution code is separated in a model within the ISV layer. Any customer specific changes to the ISV solution would be in a higher layer.

Benefits of Layers: Faster and Easier Upgrades

Upgrades and service packs contain changes in the lower layers where the base code resides. This means that any changes by partners or customers are maintained throughout the upgrade. Powerful compare and merge tools are available to guide developers through the upgrade. These tools highlight elements that are modified in higher layers and therefore might require some action to merge the changes.

As an example:

The item number is an extended data type that exists in the SYS layer. This field is a string that is 20 characters in length.

If a company that uses Microsoft Dynamics 365 requires 30 characters for their item numbers, the field length would be changed to 30 characters and the change saved in the CUS layer. The item number data type now exists in both the SYS layer and the CUS layer. The CUS layer is a higher layer so when the application is compiled, the 30 character length is used.

If in a future version, Microsoft extends the length of the item field to 40 characters, the upgrade tool would highlight that there is a change in the SYS layer to 40 characters and there is an existing change in the CUS layer to 30 characters. The developer would then have the option to keep the CUS layer change or delete the CUS layer and revert to the new field length in the SYS layer of the new release.

Next: https://www.songnghia.com/2022/09/dynamics-365-fo-developer-environment.html