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 that you can use to make modifications and additions without interfering with the application elements at 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, and 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, the ISV solution code is separated into a model within the ISV layer. Any customer-specific changes to the ISV solution would be at 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 made 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.


For example: 


The ItemID 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 ItemID, the field length would be changed to 30 characters, and the change would be saved in the CUS layer. The ItemID 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 an existing change in the CUS layer to 30 characters. The developer would then have the option to keep the CUS layer changed or delete the CUS layer and revert to the new field length in the SYS layer of the new release. 




Comments

Popular posts from this blog

How to customize electronic reporting in D365

Batch parallelism or multithreading in Dynamics 365 for Finance and Operations

How to Enable/Disable a Form Button with X++

How to create and run the Runbase batch class in D365

Build HTML and send email in D365 FO with X++

Difference between InMemory and TempDB tables in D365 F&O

Conditional Statements in X++

How to apply a package in LCS Dynamics 365 F&O

Customize the standard excel template in D365FO

How to write the event handler in D365