In 2021 a new domain structure was introduced that allows more flexibility of the object type a domain can contain. This allows for the creation of compound-domains and domains of data-classes.
It also splits the functionality into a Domain Model as described by Martin Fowler and a separate trigger handler. This helps to structure the code better and makes it more clear which Apex code should be in the domain and which in the trigger handler.
| Interfaces | Implementation | Description |
|---|---|---|
| fflib_ISObjectDomain | fflib_SObjectDomain | Used as Domain and trigger handler |
| Interfaces | Implementation | Description |
|---|---|---|
| fflib_IDomain | Generic identifier for domains | |
| fflib_IObjects | fflib_Objects | Domains constructed with Objects, e.g. data-classes |
| fflib_ISObjects | fflib_SObjects | Domain containing SObjectTypes, e.g. Accounts, Contacts |
| fflib_ISObjectDomain | fflib_SObjectDomain | Used for trigger handlers and for legacy domains |
See this PR for a detailed overview of all the code changes which were part of this change.
The fflib-apex-common-samplecode also includes examples on how to structure the change into the new domain and trigger handler
This happens when you try to mock an old domain class which is extended from fflib_SObjectDomain.
Application.Domain.setMock(mockAssetsDomain); // <<== generates Ambiguous method signature: void setMockThe issue can be resolved by casting the mock implementation to fflib_ISObjectDomain:
Application.Domain.setMock( (fflib_ISObjectDomain) mockAssetsDomain);
See this issue report for more information
The newInstance method signature of the Application Domain Factory (fflib_Application.DomainFactory) has changed into:
public fflib_IDomain newInstance(***);
If you have:
fflib_ISObjectDomain domain = Application.Domain.newInstance(sObjIds); You need to change that into:
fflib_ISObjectDomain domain = (fflib_ISObjectDomain) Application.Domain.newInstance(sObjIds);