The blog

Introduction
It is great to see how in a few months this website has grown into an impressive collection of articles around CORA. Especially the contributions by other practitioners in the field are very important. We have created the CORA model from our real life experiences as a generalization of the models and approaches that were a common factor in our projects. So to read the examples on this site (the SAP mapping by Theo, implementing repositories by Philippe and the ROA based iPhone App by Wilco and Maarten) is fantastic!

Looking at the contribution from Wilco en Maarten, one of their conclusions with regards to CORA is that the CORA model does not provide direct guidelines on where to implement business logic. It describes where it can exist, but does not explicitly state where it should be placed. They suggest elaborating on this for CORA 2.0. I think that is a very good point. Of course we had discussions about this when we worked on CORA 1.0, but I will elaborate a bit more about it in this blog as a stepping stone for  CORA 2.0. In this first part I describe the way we look at business logic from a CORA point of view. In a second blog I discuss the way this is used within the iPhone example of Wilco and Maarten.

Business Logic in CORA 1.0
We have divided CORA in an Architectural approach, the Content Model, a Project approach and Governance. I will focus on the Content Model because there we talk about the business logic subject.

We have discovered that almost all Vendor reference architectures separate business logic from other layers like presentation and data. There is also a difference between a business process as business logic and pure business logic as application code.

Within the principles we explicitly state the separation of data and business functionality, so to reuse data where new business opportunities arise. Also static business logic and dynamic business logic like business processes and business rules are separated.

Then it is interesting do see the difference in the CORA model between the Business Component/ Business Entity in the Composition layer and the Application Logic/Application Entity in the Application Layer. This will be described in the next two sections.

Business functionality within the Composition Layer
The Business Component is defined as ‘cross-domain business logic, made from composing multiple services from one or more functional domains’ and the Business Entity as ‘Cross-domain object (i.e. employee, invoice)’. Actually this entity is frequently seen as an abstracted Application Provider Interface (a provider with services) to the actual (entity-) provisioning services in the application layer. The extensive discussion we had on this part was if the Business Component could contain additional business logic and if the Business Entity could store own data. As ‘discovered’ by Wilco and Maarten we did not describe the result from that discussion in CORA 1.0 .

Our intention was that in principle the Composition layer only introduces new business logic by combining existing business logic. It does not create ‘atomic’ new business logic. So the Business Entity does not store newly defined data, but is a façade towards data services provided from the Application or Data Layer. It might store data from a technical caching perspective though.

If a decision is made to create a Business Component and Business Entity which introduces new (atomic) business logic and stores data attributes not stored in the Data layer, it is in fact a new provider of functionality and should be positioned in the Application layer.

We regard Business Processes (the four types of orchestration) and of course Business Rules also as business logic, but with a different type. The business logic in Business Processes is the implicit knowledge that is present in the process flow and the decisions. The Business Rules contains statements and rules about cross-domain rules that need or can be applied within the enterprise functionality.

Business functionality within the Application Layer
The core business functionality, as we named it, is located in the Application Layer. This layer defines tree types of applications: Make, Buy and Legacy. Each has two elements: Application Logic and Application Entity. Application Logic is defined as ‘A set of specific coherent business logic’ and Applications Entity as ‘Application specific object (i.e. customer, order)’. From a SOA architecture style point of view new providers with services (or SCA components) are ‘Make’ or ‘Buy’ in the Application layer. They can be combined in a composite service in the Composite layer as a new Business Component or as a Business Process.

Interestingly we should also look at the Integration Layer. Transformation rules, schemas, event processing etc. all contain a certain amount and type of business logic. But again, with a different perspective and purpose.

This is what is described in CORA 1.0 about business functionality.

In the next blog I use the IPhone example of Wilco and  Maarten to discuss the positioning of business logic in their example.

About the author
Joost van der Vlies is one of the co-authors of the CORA Model. He is working at Hewlett Packard in Shanghai, China. The views of this blog are his own and are not related to his employer or its affiliates.