Brett, 

Thanks for taking the time to provide a well thought out solution. 

Judging by your description above, you have provided the appropriate level of implementation required for this particular question assuming that the stages, steps and flows are sufficiently documented to communicate the functionality.  This case design question would have been overly challenging to implement a fully functional solution considering there are several additional questions to answer. Some candidates submitted solutions which attempted to implement a fully functional application. This was not warranted for this question and came at the expense of not fully answering the other exam questions.

Please keep in mind  however, that other exam scenarios may require you to create a functioning application. This will be indicated in the deliverable section of the question. 

We attempt to set the level of implementation required in consideration with the overall challenge level of all questions in the exam. For example, this exam had 6 questions therefore it was not suitable to require a fully functional solution. Other exam scenarios have 3 or 4 questions, therefore we may indicate that a functioning application would be required. This is indicated in the deliverable section of the question therefore please read this section carefully to determine the level of implementation required.

General comments on your documented solution are that it was well documented and clearly displayed the thought process which supported your design particularly in the areas of cases. A quick estimate on your score for the design question would be 90%. Some comments are:

- Excellent consideration of the cases as this is the main challenge. The discussion was focused on that while also expanding to cover the additional areas to consider. 

- You have documented the data objects, however it is difficult to visualize what the relationships would be between the data objects / cases and how they would satisfy the reporting requirements. A simple diagram indicating the high level relationships between the data objects / cases may help, and it would break up the wordiness.

- Some decisions were not convincing, such as the placement of the Selections case under the Enrollment case.

I want to emphasize the following point which should be mentioned for the benefit of other exam candidates (which doesn't apply to this submitted design as it was very well done) : Too often, candidates will generate a design in their head, implement it and just document their provided solution without providing the full rationale to support their design. This would lead to a poor score for the design question as it does not give the grader any indication on the scope of the candidates consideration when determining an optimal solution.

Contest – Top Level case

• Tournament ( Sub case of Contest) – Each contest have 1 or more tournaments
  • Enrollment (sub case of Tournament) – Each Tournament can have 1 or more contestants- We have guidelines that Contestants can register one week before each tournament, Auto approved if registered within 2 days before tournament, Contestants will be notified the list of players 4 days before the tournament.
    • Selection– is a sub process in Enrollment case type.

However, there is no requirement explicitly stated that same contestant should participate in all Tournaments for the contest. Also, Contestant enrollment is dependent on the first Tournament start date.  As I understand that we are focused to build the MLP first, but we may have to think in advance about the application needs to be extended as feature requirements grows… 

1. What happens if we have the reporting requirements in the future to publish the list of contestants and their team of players along with Tournaments by end of each contest.
2. What happens if there are requirements to add/modify the contestants in the feature for each tournament?              
3. What happens if there are SLA requirements for each contestant to pick their players before the start date of each Tournament.

Here is what I visualized, so feature requirements could be easier to implement rather than redesign.

Roles:

Constest – Contest Manager

Tournament – Contest Manager

Enrollment/Contestants – Contest Manager will approve the contestants, Contestants will pick their players during the selection process.

.

Recently I received the following proposed solution for the Wagering Application.  I received this proposal from a CLSA Candidate Preparing to Take the CLSA Application Build Exam. I am presenting it here  so I can share my feedback with other CLSA candidates:

Recommend Design Approach. 

The best case design solution in my opinion is to have a parent Contest case that spins off a Tournament subcase for every Tournament approved by the Contestant Manager. In addition, an Enrollment case would spin off  as subcase for each Contest.

Key Influencing Factors: 

• Reporting needs related to Each of the Tournament.
• Can easily handle Extensibility & Specialization for other sporting events.
• Using Dependency Management processing can be easily controlled between Contest(Parent) and Tournament & Enrollment (Sub cases) cases.
• Enrollment process can be different for other sporting needs, Having it as a sub-cases would help resolve the issue.
• Class-based security offers more options for security refinement using multiple cases.
• Data security increased as subcases only contain data pertinent to their case

General Assumptions:   Application would be extended for other sporting needs very soon and is a key requirement.

Design(s) Considered But Rejected: 

1.            Each Tournament can be part of the Same case processing using a Split-for-Each approach. However Security needs & Extensibility for other sporting needs will be complex with only limited options.

2.            Enrollment can be part of the Main case and we can use Split-for-Join approach.

Recommend Design Approach Detail

• The list of tournaments and their start dates is received by the Contest case, Contest Manager determines the tournaments included in the contest.
• A week before the First Tournament a Case step type is used to spin off a Tournament & Enrollment sub-cases and send email to Contestants informing of Enrollment.
• Contest case will spin-off additional sub-cases based on the list of approved tournaments and corresponding dates.
• Case Designer-configured Data Propagation is used to send Start Date Information into each spun-off Enrollment and Tournament case.
• Within the Case Designer, Tournament & Enrollment cases are configured as “Do not lock parent case” which allows Multiple contests run simultaneously, independent of one another.
• Golfers Information is retrieved from each Tournament case.
• A day before the first tournament Enrollment is closed and the case is resolved.
• End of each tournament, results indicating the money earned by all golfers will be retrieved and info will be shared with contestants and resolve individual tournament case.
• Once all tournaments related to the same sporting event for the year end. The parent contest case will resolve.

 Why a sub case approach makes sense:

1. Both Tournament and Enrollment cases will be resolved before Parent Contest case can be resolved.
2. The reporting needs of the Context and Each of the tournament can be easily handled and offers better performance.
3. Security restrictions between each of the cases can be easily handled.
4. Option to Specialization for other sporting events.
5. Sub-cases allow pure parallel processing since tournaments cases from other events may be accessed using a separate requestor without any Issues.

 Alternate Solution #1

• As opposed to spinning off a subcase for each Tournament in a Contest case, a Split-for-Each shape can be used to spin-off a sub-process.
• All Data i.e., regarding Tournaments, Golfers, Contestants is readily available.
• All Data belongs to the same case and is accessible for reports.
• Tournament-specific data propagation is configured via the Split-for-Each shape.
• There is no need for case-to-case Data Propagation.
• Since no 2 tournaments of the same sport occur at the same time, locking would not be a problem for the current sport(golf).
• Enrollment too can be a Sub Process using Split-for-Join approach.

Primarily because of extensibility and security restrictions in one approach and flexibility in the other I choose the other approach over the same-case approach.

Conclusion: 

My recommended solution meets today’s needs at no extra cost. Over time, this simpler-to-maintain design will lead to cost savings. Extensibility, Specialization and Security flexibility is both simplified and maximized.

In reference to ERD diagram, something not mentioned in the 7.3 LSA course, but perhaps will be in the next, is the Law of Demeter.

If you strive to define only one path to navigate to an object you will end up with a more object-oriented design due to separation of concerns, single responsibility, encapsulation, etc.

Take for example your Enrollment case/object.  An Enrollment case does not need to know anything about a Tournament or have a PlayerList.  An Enrollment case only needs to know what Contest it is enrolling in and the deadline by which to enroll. The Enrollment case can ask the Contest what Tournaments are included in the Contest. The Contest can also act as a Proxy to each Tournament to retrieve its List of Players.

A Contestant’s post-enrollment selection of Players per Contest Tournament is purely Data. That data would contain the keys to the Contest and Tournament, Contest and Tournament having a M:M relationship as you have shown in your ERD diagram.

As for your Application Structure, I would question the need for a framework layer. MyCo’s business is based on hosting Contests. What sport the Contest involves is secondary and could be handled by specialization techniques well within Pega’s capabilities without having to resort to a complete separate Application per sport.  Just because MyCo’s Business wants their initial Minimal Lovable Product (MLP) to support golf tournaments does not imply that every future release that involves a new sport should be a new Application.

What is missing from you Application structure is an enterprise-wide reuse layer. With your design, if MyCo wants to develop applications for purposes other than Contests, e.g., a Marketing, Sales, or Billing application, those applications would also need to be built on your SportsWager FW layer, which does not make sense. If, however, the generic Data classes for Contest, Tournament, Contestant, etc., are included in an enterprise-reuse, COE-manager application layer, then any application, not just SportsWager, can leverage those Data classes.

Your first “pro” for having an FW layer is “Maximize reuse of rule and promote COE”. If you were to remove “-FW-“ from your design document, that statement would be unquestionably accurate.

Please let me know if the following Case Design Approach makes any sense and whether reasoning behind the approach is well supported.

Case Design

Contest and Enrollment have 1:1 relationship (each Contest can have only One enrollment).

So both Contest and Enrollment can be Case Types.

Tournament details are just Data. There is no process involved, so creating a case type for tournament is unnecessary. It can easily be combined with other case information to present Details Per Tournament in a UI.  For example- Portal for Contestants can have a repeated Grid UI for each Contest they have enrolled into and each grid can present 360 view of Tournaments' details combined with contestants' and their opponents selections of golfer(s),results etc.( UI can be a Collapsable section/Modal Window/ Link etc can be used). We can show and hide certain details based on tournament's Start and End Dates. such as selection of golfers/prize Money/Tournament results etc. 

Selection (golfer) involves process & SLA dependency, so it can be a child case of Contest. Each Selection case is created at different intervals based on list of Selected tournaments and their start date. 

Based on above analysis following is the recommended approach:

Contest (Top level Case) [FCLB-Wager-Work-Contest]

 -Enrollment (Child level Case) [FCLB-Wager-Work-Enrollment]

 -Selection (Child level Case)[FCLB-Wager-Work-Selection]

Contest Case will be wrapped up when :

-enrollment case is resolved

-all selection cases are resolved

-all selected tournaments within a contest are over and their results are out.

-prize money and winner of the contest are evaluated and notified.

I appreciate any suggestions or feedback.

Your suggestion to use case type pattern-inheritance is a good one.

An advantage of using pattern inheritance is that you can leverage the Case Designer within the same application to define the abstract, reusable portion of a case type.

At the same time within the same application the Case Designer can be used to define how the concrete, pattern-inheriting case type classes are specialized 

Remember, in development mode you can do whatever you want with an Application rule as long as it does not impact how the Application operates in Production.  For example you can define a development-only Application built on your Production Application. The development-only Application can do a number of things besides contain test rulesets.

My recommendation is to not spend a lot of time discussing an alternative that is not a good fit, especially if it is the first idea presented. You started out talking about the possibility of having a framework layer across every case type in the application. 

If this is something you are not going to recommend, then simply summarize why and move on to talking about what do want to recommend.

This is how an "argumentative essay" should be written. You want to "sell" your recommended idea. The more you talk about something you do not recommend, the less time your audience hears about what you do recommend. Plus, audience interest tends to fade when listening to negatives, especially if you start out talking about negatives.

Back to the idea of having an "abstract, reusable portion of a case type" from the beginning. This avoids pushing reusable rules to the work pool level. The Application rule, application-level Data classes, and work pool class, IMHO, belong in their own separate ruleset and case types should have their own separate ruleset.

If you do not start out like this and later realize that the "abstract, reusable portion of a case type" could be converted to a built-on Component application, you do not then have to deal with pulling rules that are used out the work pool class 

Keep dependencies to a minimum. The same applies to Data classes.

You can reference Data classes from the next layer down, e.g., the Enterprise layer, then use DCR to get at application-level Data class overrides.

If properties have been added to application-level Data classes and those need to be used, fine.  Application-level case type code can reference those application-level Data properties. At the same time using direct inheritance, application-level case type code can leverage code from a built-on Component application.

This is the same as what occurs when a framework is used. The difference is that a framework typically spans every case type within the Application.

Components are modular. They can be reused by other applications. Design Patterns are reusable. A Design Pattern consists the minimum number of classes possible to implement a certain type of functionality.

Besides too much detail about the framework option you also included multiple screenshots of your build's Case Stucture. You called it "Case Structure as designed",  This is after-the-fact documentation; a grader can see this for themselves.  You had already described your case structure verbally highlighting key aspects of the design.

The Data Model diagram is great. Would prefer that the class names drop the word "Wagering" to allow other applications to use those classes. You did use generic class names and properties for the most part, nothing truly Golf-specific, which is good.  Not every sport has "prize money" and "Tournament" typically applies to individual player sport. Basketball is a team sport but there are basketball tournaments. The enterprise level Data classes could be specialized at the application level. The Tournament Golf case specialization could leverage a Golf-specific Data property for example the golf course name, number of holes in the golf course.

Perhaps mention whether the relationship is aggregation (embedded) or assocation. One could mistake Contest as having an embedded Page List of Tournaments (SportContest?). That is an M:M relationship also. This was not indicated in the case design.  You show Contest and Tournament as sibling case types but what is the relationship between them?

You can mention Email as something that can be a Component but that is something straight out of the course. What is more challenging is to mention the possibility of a new and unique Component.  Perhaps whatever it is that collects tournament results could be made into a reusable Component. You do not have to build it out. Mentioning something creative helps keeps a Business reader's attention, especially if it is something that would differentiate them from their competition, i.e., give them a "leg up".