Facade Pattern is a Design Pattern to hide complexity of the multiple sub systems by providing a simple interface to the client. This pattern involves a single codeunit which provides simple methods required by the client and delegates call to methods of existing internal codeunits.
The Rules Pattern is a Design Pattern to simplify the complex business logic which is based on multiple if-else statements. Using this Design Pattern each if-else branch in the business logic is segregated into a separate rules and also the processing logic is separated from the rules.
In our Org we have quite a few places were data is auto populated based on other data selected. This however comes with allot of rules. When I started, we had allot of issues where sometimes the incorrect data is selected. This required a rewrite of the filtering to find the correct data but often caused the “fix” to break another set of data combinations.
Not too long ago, I was facing the issue that I needed to be able to make any record so that I could transfer this record – I wanted to be able to find a way to take any record and be able to transfer it to a façade codeunit, to an event subscriber, well, maybe even email the record.
After applying Sensitive Data Encapsulation, all sensitive data is gathered in a known place in the database. This makes it possible to apply further protection best practices. Problem: If any non-authorized actor manages to get access to a copy of the database, the sensitive data is immediately available in clear-text.