Software "stack" -- separation of concerns:

1. Prerequisite is the traditional architectural layering of application, where:
1. Presentation layer contains only "presentation logic" -- code, that is needed to organize the presentation (mapping) of business information on screen, and to accept and validate the user input from the input devices (e.g. keyboard and mouse). Presentation layer is usually specific to the given user interface device (e.g. web, GUI, mobile phone, ...). As much as possible presentation logic should be declarative (e.g. layout and mappings) or generated.
2. Business Process layer contains "process logic" -- code, that integrates the business functions into business processes, organizes the access to the business rules, and flow of control and information through the business functions. Business process layer manages conversational state and business transactions (sessions). Externalization of process logic and business rules allows easy reconfiguration of business functionality and provides flexibility required by the business. Business rules should be side-effect free and as much as possible declarative.
3. Business Service layer contains "business logic" -- code, that performs transactional business functions or business services, packaged into business service components (usually business functions are grouped around "subject areas" -- e.g. business functions dealing with same business information should be grouped together). Business functions are usually transactional and stateless, they delegate all the state-management and data-intensive functionality to the database layer components. Business service layer could be further divided into two sub-layers: complex business functions and elementary business functions that are reused by the complex business functions to perform their task. Statelessness of business services allows easy scalability by deploying more instances of business service components.
4. Database layer contains "data access/processing logic" -- that is code, that encapsulates access to business data (implements mappings to data store structures), enforces syntactic integrity constraints on business data, and performs or delegates data-intensive business functions to the data store execution engine (stored procedures). As much as possible data access logic should be declarative (e.g. mappings) or generated.
5. Integration layer contains "integration logic" -- that is code, that encapsulates connections to other applications (implements mappings to external data formats, and manages conversational state connected to integration). As much as possible integration logic should be declarative (e.g. mappings) or generated.


2. All layers could be, if needed, distributed over different processes and/or computers.
   

(A business function is a function that gives business benefit to the user, it is often specified/described by a business use-case.)

Guidelines for implementing and packaging business logic:

1. To identify what is the business functionality in given application, following question should be asked: "What remains unchanged, if the user interface and data storage technologies will change?".


2. As much as possible (when using J2EE platform):
1. All presentation logic should be implemented in presentation layer (using JavaScript/Java or Flex or whatever has chosen).
2. All process logic, management of conversational state, and business rules should be implemented in business process layer (using BPEL/Java).
3. All business functions that do not need large amount of data should be implemented in business service layer as business services (using Java).
4. All business functions that need large amount of data should be implemented in database layer (using stored procedures).
5. All business state should be managed in database.


3. Interfaces for business functions should (when using J2EE platform):
1. Be defined using Java (and all bindings to other systems (e.g. WSDL/XSD for WS) will be generated from the service interface definitions),
2. Should be coarse-grained to avoid latency problems related to the remote access,
3. Conform to rules for remotable interfaces (take into account that methods could be called remotely),
4. Always have a service context (representing business context, time context and technical context) as a required input/output argument of every method (this could be used for carrying conversational state is such need will arise -- e.g. partitioning result of a method that returns large amount of data),
5. Contain extension points that could be used to extend/customize the business function (without changing the public interface of business function),
6. Use synthetic technical IDs or keys (which should not containing business data) to represent identities of business objects in the interface (such IDs should be considered temporary -- e.g. users of business functions should not rely that they are same in successive uses of given business function),
7. Use return values for communicating business exceptions,
8. Use Java exceptions only for technical exceptions.
9. Be documented according to the JavaDoc best practices, so that for every method in the service interface following is described:
1. The business function performed ("what"),
2. The meaning of input and output parameters,
3. The meaning of technical exceptions,
4. The purpose and usage of the method illustrated with examples.


4. Business service components should have following interfaces:
1. Business service interfaces, through which all business functions that given business service component offers, could be accessed.
   If needed business service should have two separate business service interfaces with different granularity to be used for different situations:
1. Fine-grained interface (where single transaction requires small amount of data and provides small piece of business functionality) for local usage where transport mechanism provides low-latency connection to the service component, and
2. Coarse-grained interface (where single transaction requires large amount of data and provides large  piece of business functionality) for remote usage where transport mechanism provides high-latency connection to the service component.
2. Configuration interface, through which the variability offered by the business service component is configured (usually during setup/startup process).
3. Management interface, through which service component could be identified (for configuration identification) and managed during run-time.
4. Service provider interfaces for other business or supporting services that given business service component requires for performing its functions


5. Reusable assets should be treated same way as third-party products:
1. Reusable assets should have:
1. Dedicated development team.
2. Its own development goals, roadmap (together with a process for collecting feature requests), and release cycle (changes to the public interfaces should be done through deprecation and phase-off cycle).
3. A support service (together with a process for reacting to the defect reports and releasing fix-packs).
2. Reusable asset should be isolated from the "client code" by isolation and customization layer.
3. Package of reusable asset should contain:
1. Release notes.
2. Developer's package:
1. Programmer's Guide;
2. Programmer's Reference;
3. Installation scripts and database scripts (creation and upgrade);
4. Interface definitions;
5. Development binaries (if such are different from production binaries) and parameter files;
6. Source code for debugging purposes;
7. Development dependencies (if such are different from production dependencies);
8. Usage (and customization) example(s) with the build scripts.
3. Operational package:
1. Installation and Configuration Guide;
2. Operation and Administration Guide;
3. Installation scripts and database scripts (creation and upgrade);
4. Production binaries and parameter files;
5. Production dependencies.