Avoid creating a Framework layer "just in case".

If you can generalize the requirements for multiple business scenarios - specifically the case and work processing, providing thoughtful extension points - this is a good candidate.

The classic use case is a standardized workflow performable by different lines of business that have slightly different requirements.

Another scenario is data storage for regional implementations layers or SaaS applications. 

Use an Enterprise Reuse layer when the components are granular and shared across the organization.

Use a Framework layer when there is intended reuse across multiple specific implementations including complex workflows.

Both Frameworks and Enterprise layers attract the considerations needed to provide reusable capability to layers that build on them.

It is not mandatory to build a Framework and an Implementation layer. That is, an Implementation layer can be built with no Framework layer.

If you do have both a Framework and Implementation layer, then they should have their own rulesets, classes, and application.

Yes, it does. 

The Framework rulesets must be associated only with the Framework application. The Implementation application then builds upon the Framework application.

Design for extension.

Identify extension points in an otherwise common process, and also some of the Object-Oriented themes from this session.

Also consider where the reuse layer should reside. For example, if you have a Customer Service application and a Platform application, a Framework built upon Customer Service wouldn't provide value to Platform implementations across the organization.

Refactor the generalizable portions of the Implementation into a new Framework layer.

Having the Implementation application assume the role of a Framework application results in coupling of peer applications.

Although it depends on the situation, putting all data classes in the Enterprise layer can make it a huge dependency.

One alternative is to create data classes in finer-grained components that can be added to an application when needed.

If you build an application that requires physical data segregation (that is, separate databases/schemas) as well as having country specific reuirements, the infrastructure may need to be hosted separately which would mean multiple implementation layers.

Build out the extensible and configurable functionality in the Framework layer, and any country-specifics at the Implementation layers for each country. 

Assessing your Framework needs is an ongoing process, regardless of what version you started work on, or whether the work was done by another team.

If you find that Framework is not providing intended value, consider consolidating it into the corresponding Implementation.

If I have a data class defined in a reuse layer, should I create a subclass for it in the Implementation layer? 

For example: Org-Data-Party <---- Org-ImplLayer-Data-Party

This is recommended.

Let's say you do not create a corresponding Implementation layer class and - at some point in the future - you need to define implementation specific behaviour for that class. Adding that rule in a Framework class - but residing in an Implementation layer ruleset - is poor design, "mixes" the layers, and defeats the purpose of having layers in the first place.

Creating the class after the initial development means updating any instantiation processes to use the appropriate class (Dynamic referencing!) as well as updating any previously created cases. Save yourself a headache in the future and build out the corresponding Implementation layer data classes at the start of Implementation development.

Building a Framework - and then effectively utilizing it - takes planning and work. It cannot just be an afterthought. 

Java developers can mark behaviour as "private" to control their access.

All rules in Pega are available for reuse. Can we forbid the usage rules that exist to implement part of another feature?

There is not an equivalent concept of "private" access to rules in Pega.

Leverage encapsulation, composition and delegation of concerns to encourage appropriate usage of rules for the types of data your application uses.

What is the best data design to use when properties are reusable across case types? 

Definitely evaluate if you can achieve your use case with Data Pages first.

Obj-* methods are limited to Activity rules; Data pages can be used in many different use cases and nicely encapsulate the retrieval logic.

1. Add a Save data page automation step in a Flow rule;
2. Use the Savable Data Page post-processing configuration on a Flow Action rule; or
3. Call the Save-DataPage method if in an Activity rule.

Branch Development Preferences - when developing in Branches - is the strongest influence you can apply to direct rules authored in App Studio into the relevant ruleset.

Brian Pageau (@pageb) wrote a great blog post on the topic: How branch development works in Pega App Studio