{"id":375,"date":"2015-01-27T11:10:11","date_gmt":"2015-01-27T11:10:11","guid":{"rendered":"http:\/\/adriangrigoras.com\/blog\/?p=375"},"modified":"2015-01-27T11:10:11","modified_gmt":"2015-01-27T11:10:11","slug":"business-layer-checklist","status":"publish","type":"post","link":"https:\/\/adriangrigoras.com\/blog\/business-layer-checklist\/","title":{"rendered":"Business layer checklist"},"content":{"rendered":"<h3>Design Considerations<\/h3>\n<ul>\n<li>A separate business layer is used to implement the business logic and workflows.<\/li>\n<li>Component types are not mixed in the business layer.<\/li>\n<li>Common business logic functions are centralized and reused.<\/li>\n<li>Design reduces round trips when accessing a remote business layer.<\/li>\n<li>Business layer is not tightly coupled to other layers.<\/li>\n<\/ul>\n<h3>Authentication<\/h3>\n<ul>\n<li>Users are authenticated in the business layer, unless they come from another layer on the same tier to which you are willing to extend full trust.<\/li>\n<li>Single sign-on is used, if your business layer will be used by multiple applications in a trusted environment.<\/li>\n<li>The original caller is not flowed to the business layer, unless it\u2019s necessary to authenticate based on the original caller\u2019s ID.<\/li>\n<li>Trusted sub-system is used for access to back-end services to maximize the use of pooled database connections.<\/li>\n<li>IP filtering is used when using web services, to only allow calls from the presentation layer<\/li>\n<\/ul>\n<h3>Authorization<\/h3>\n<ul>\n<li>Users are authorized based on their identity, account groups, claims or roles.<\/li>\n<li>Role-based authorization is used for business decisions.<\/li>\n<li>Resource-based authorization is used for system auditing.<\/li>\n<li>Claims-based authorization is used to support federated authorization.<\/li>\n<li>Impersonation and delegation are not used unless absolutely necessary and the performance trade-offs are well understood.<\/li>\n<\/ul>\n<h3>Business Components<\/h3>\n<ul>\n<li>Business components do not mix data access logic and business logic.<\/li>\n<li>Components are designed to be highly cohesive.<\/li>\n<li>Business rules are implemented in business process components to keep business rules separate from business data.<\/li>\n<li>Volatile business rules are stored in a rules engine.<\/li>\n<li>Workflow components are used, if the business process involves multiple steps and long-running transactions.<\/li>\n<\/ul>\n<h3>Business Entities<\/h3>\n<ul>\n<li>Appropriate data format is used to represent business entities.<\/li>\n<li>Domain Model pattern is used for designing business entities, if the application needs to support complex business model.<\/li>\n<li>Table module pattern is used to design business entities, if the tables in the database represent the business entities.<\/li>\n<li>Business entities support serialization if they need to be passed over network or stored directly to the disk.<\/li>\n<li>The Data Transfer Object (DTO) pattern is used, to minimize the number of calls made across tiers.<\/li>\n<\/ul>\n<h3>Caching<\/h3>\n<ul>\n<li>Static data that will be regularly reused within the business layer is cached.<\/li>\n<li>Data that cannot be retrieved from the database quickly and efficiently is cached.<\/li>\n<li>Data is cached in ready-to-use format.<\/li>\n<li>Sensitive data is not cached.<\/li>\n<li>Web farm deployment scenario considered, while designing business layer caching solution.<\/li>\n<\/ul>\n<h3>Coupling and Cohesion<\/h3>\n<ul>\n<li>There are no circular dependencies between layers of the application.<\/li>\n<li>The design doesn\u2019t require tight coupling between the business layer and other layers.<\/li>\n<li>The business layer is designed to be tightly coupled within itself.<\/li>\n<li>The business layer components are highly cohesive.<\/li>\n<li>Data access logic is not mixed with business logic in the business components.<\/li>\n<\/ul>\n<h3>Concurrency and Transactions<\/h3>\n<ul>\n<li>The design defines transaction boundaries, so that retries and composition are possible.<\/li>\n<li>A compensating method to revert the data store to its previous state is used, when transactions are not possible.<\/li>\n<li>Locks are not held during long-running atomic transactions, compensating locks are used instead.<\/li>\n<li>Appropriate transaction isolation level is used.<\/li>\n<\/ul>\n<h3>Data Access<\/h3>\n<ul>\n<li>Data access code and business logic are not mixed with the business components.<\/li>\n<li>The business layer does not directly access the database; instead a separate data access layer is used.<\/li>\n<\/ul>\n<h3>Exception Management<\/h3>\n<ul>\n<li>Exceptions are not used to control business logic.<\/li>\n<li>Exceptions are caught only if they can be handled<\/li>\n<li>Appropriate exception propagation strategy is designed.<\/li>\n<li>Global error handler is used to catch unhandled exceptions.<\/li>\n<li>The design includes a notification strategy for critical errors and exceptions.<\/li>\n<li>Exceptions do not reveal sensitive information.<\/li>\n<\/ul>\n<h3>Logging and Instrumentation<\/h3>\n<ul>\n<li>Logging and instrumentation solution is centralized for the business layer.<\/li>\n<li>System-critical and business-critical events in your business components are logged.<\/li>\n<li>Business-sensitive information is not written to log files.<\/li>\n<li>Log failure does not impact normal business layer functionality.<\/li>\n<li>All access to functions within business layer are audited and logged.<\/li>\n<\/ul>\n<h3>Service Interface<\/h3>\n<ul>\n<li>The service interface is abstracted from business logic changes.<\/li>\n<li>The service interface does not implement business rules.<\/li>\n<li>Service interfaces are designed, for maximum interoperability with other platforms and services.<\/li>\n<li>The service does not make any assumptions on how the service will be used.<\/li>\n<li>An appropriate transport protocol has been chosen.<\/li>\n<\/ul>\n<h3>Validation<\/h3>\n<ul>\n<li>All input is validated in the business layer, even when input validation occurs in the presentation layer.<\/li>\n<li>The validation solution is centralized for reusability.<\/li>\n<li>Validation strategy constrains, rejects, and sanitizes malicious input.<\/li>\n<li>Input data is validated for length, format, and type.<\/li>\n<\/ul>\n<h3>Workflow<\/h3>\n<ul>\n<li>Workflows are used within business components that involve multi-step or long-running processes.<\/li>\n<li>Appropriate workflow style is used depending on the application scenario.<\/li>\n<li>The workflow fault conditions are handled appropriately.<\/li>\n<li>The Pipeline pattern is used, if the component must execute a specified set of steps sequentially and synchronously.<\/li>\n<li>The Event pattern is used, if the process steps can be executed asynchronously in any order.<\/li>\n<\/ul>\n<h3>Deployment Considerations<\/h3>\n<ul>\n<li>Business logic is deployed on a physically separate machine, only if it\u2019s really required.<\/li>\n<li>Message-based interface is used for the business layer, if the business layer is to be deployed on remote tier.<\/li>\n<li>TCP protocol is used if the business layer must be on a separate physical tier.<\/li>\n<li>IPSec is used to protect data passed between physical tiers.<\/li>\n<li>SSL is used to protect data passed to remote Web services.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>Source: apparch.codeplex.com<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Design Considerations A separate business layer is used to implement the business logic and workflows. Component types are not mixed in the business layer. Common business logic functions are centralized and reused. Design reduces round trips when accessing a remote business layer. Business layer is not tightly coupled to other layers. Authentication Users are authenticated\u2026 <span class=\"read-more\"><a href=\"https:\/\/adriangrigoras.com\/blog\/business-layer-checklist\/\">Read More &raquo;<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[30],"tags":[],"class_list":["post-375","post","type-post","status-publish","format-standard","hentry","category-architecture"],"_links":{"self":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts\/375","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/comments?post=375"}],"version-history":[{"count":1,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts\/375\/revisions"}],"predecessor-version":[{"id":376,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts\/375\/revisions\/376"}],"wp:attachment":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/media?parent=375"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/categories?post=375"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/tags?post=375"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}