- Created by Unknown User (b.de.veer), last modified by Unknown User (m.schadd) on Nov 20, 2017
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 14 Next »
Summary
In a complex application decisions have to be made whether a person is allowed to perform a certain action. This is frequently encountered in Dynamic Case Management applications where a user is only allowed to perform a subset of tasks. You may also encounter it in applications without process engine, where the end user is not allowed to see certain information based on some criteria.
As the user permission example does not concern the core business rules of a company, but a way of structuring the work of its employees, is the Application Layer the appropriate location for this scenario (arrow 5). External systems may use the same logic for deriving user permissions (arrow 4).
Security is a separate concern and ideally should not be mixed with the core of the domain. When mixed, these could intertwine and get more difficult to maintain. Having these separate, makes it clear what is authorization, and what is core business.
Contents
Context
For the user permission example the following categories are important.
Type | |
---|---|
Knowledge | Implicit vs. Explicit call |
User set vs. System set | |
Input and Output parameters vs. complex model | |
Simple input vs complex input | |
Maintainability It should be possible to quickly make changes to business rules independent of other functionality. | Complexity of the Decoupling pattern vs Gain |
Internals invisible vs visible (encapsulation) | |
Testable | |
Autonomy/decoupling | |
Reusability | |
Out of the box vs. Custom Code. |
Problem
A good example can be found in a DCM application for mortgage applications. Based on the current application the system has to decide whether the Junior Mid-Office employee is allowed to make the approval decision, or if a more senior role is needed. The stakeholders may decide that any property with a value under half a million can be done by junior employees, while anything above has to be done by a senior employee. Furthermore the user should not have performed previous tasks for the application, to adhere to the four-eyes principle.
The problem of this case is not how to create such logic, as that is perfectly doable using Blueriq's rule engine. The problem lies in the maintainability of the application. Logic for user permissions is different to other logic (e.g., calculating a mortgage amount) and mixing them may decrease the maintainability. User permissions concerns the manner in which knowledge workers interact with the system, not with the domain at hand.
Solution
The solution direction that are interesting to this problem concern the separation of the logic for the user permissions and the logic for the application itself. The following patterns are relevant in this example.
Implementation characteristics | Property | Pattern 5: Function | Pattern 6: External rule | Pattern 9: Stacking of modules [editor] | |
---|---|---|---|---|---|
Decision management | Implicit vs. Explicit call | ||||
User set vs. System set | |||||
Implicit calls | |||||
Implementation property | Autonomy | ||||
Maintainability | |||||
Re-usability | |||||
Out of the box |
Decouple Category
Properties
Property | Description |
---|---|
Decouple category | Application function (5) |
Complexity | Low |
Related patterns/Solutions |
|
Webservice
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Function
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
External rule
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Stacking of modules
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Issues and considerations
Issues and considerations.
- No labels
Didn't find the answer you were looking for? Try the advanced search!