In the LSA course: How does an app-layer Application rule "control" the content of an enterprise layer ruleset?
This question is in response to material in
- the LSA course
- Unit 6, Data Model Design
- Lesson 6.1, Designing the Data Model
- Page 4: How to extend a data class to higher layers
How does an app-layer Application rule "control" the content of an enterprise layer ruleset?
This page presents a design pattern in response to the question: how best to define Org-level data classes particular to the domain of a specific application?
For instance, suppose
- the Auto Loans department of ACME SuperCorp is working on a new AutoLoan application for processing auto loans
- in the enterprise layer (ACME-Data-) are several data classes useful to all departments and applications. E.G. Customer, Building, Person
- The Auto Loans division starts work. They decide to implement data classes:
They realize that the other departments at ACME, for instance the Insurance department, would benefit from their work. The Vehicle-related data classes would be helpful to other departments. However, other departments would NOT benefit from inheriting Auto loan Case types. Therefore it does not make sense to use AutoLoan as a built-on application for other department applications.
Plan B: add the Vehicle classes to the Enterprise layer ruleset ACME. However, the ACME ruleset is already large. Adding these classes to the ACME ruleset would tie the Auto Loans department to the release cycle for the ACME ruleset, which is quite involved because every application in ACME Supercorp depends on it.
Plan C: the lesson I'm asking about recommends creating a ruleset specific to the data classes developed for the app (in this case, the Vehicle classes) and placing that ruleset in the Enterprise layer:
"You could also create a new ruleset synonymous with the <App>, but where data classes are added to the <Org>-Data class. This approach allows for applications to introduce a new, generic data type that can be referenced by other applications."
In this case: the Auto Loans department would
- create an Auto ruleset
- define the classes under ACME-Data-Vehicle in the new Auto ruleset
- include the Auto ruleset in the Enterprise layer application (NOT in the application layer AutoLoan application)
- develop Case types in AutoLoan that use classes from Auto
I understand this so far.
Here's the bit that confuses me
"The case type-containing application would control the content of this enterprise-level Data ruleset."
The "case type-containing application" is the AutoLoan app. How would it "control the content" of the Enterprise-layer Auto ruleset?
The AutoLoan TEAM could control the Auto ruleset by setting passwords on it and not sharing them, or only sharing them with the COE. But this training topic specified that the "case type-containing application" has control, and I don't see any way to implement that. I'm not sure it's necessary, but I don't want to miss a feature that may be valuable, so I'm asking here.
The word "control" can be interpreted multiple ways. The word "ownership" is more specific.
There is a warning when the same ruleset is used in different Applications -- different versions of the same Application is fine. The COE can define an enterprise application that contains every enterprise-level ruleset. When your application is built on the enterprise application. and your application does not require certain rulesets that are included in the enterprise application, you are free to remove them (unless locked down).
On a side note, Java defines numerous packages but you do not need to include them all. Java 9 introduced the concept of "modules" where multiple related packages can be managed as a set.
FYI: We are in the process of developing the 8.3 LSA course material. We are making every effort to improve the way certain areas in the course are worded, plus include more and better examples.