Salesforce 架构篇总结（一）理解 SOC

主要目标

解释 SOC 用于商业的价值
在使用一些需求或者平台技术中使用 SOC 来适用一些解决方案
将 SOC 应用到 Force.com 中
什么时候决定使用 SOC 技术

作为一个 salesforce developer 不能仅仅停留在为客户解决一些业务逻辑方
面的问题，并且作为一个公司产品的后端程序猿，更为重要的是当产品迭代到一定
程度，随着难度的加大以及业务复杂度的加深，我们需要在开发中融入一些重要的
编程核心的思想，方便及时发现产品中的 bug 以及对产品后期可扩展性方面都有
不错的提升。

对于SOC(Separation of Concerns) 的理解

广义上来说SOC是一种分层思想的体现，在大多数OOP语言中都有涉及，这里不再赘述，但需要强调的是，代码的功能模块是可以不断复用的，我们不提倡 copy & paste，但要时刻想着复用，并且类的命名规范（class naming conventions），变量名的命名规范（variable naming conventions）都有助于代码可读性的提升，好的代码如同讲一段优美的故事，That is Good code should tell a story.

SOC 的一些好处

顺应技术革命的潮流（Evolution）

技术不断在进步的进步的同时保证代码层级之间是可以扩展，修改，甚至要做到可以使层级之间拆卸自如，回想前端框架数十年发展的太快了，心疼前端小伙伴，各种全家桶层出不穷，学也学不完，都是好学霸

对影响的管控（Impact management）

当修改或者拆卸掉一些层级组件的时候，应尽量避免影响到其他层级的功能，除非是出于设计的考究而去有意去修改的

角色及其职能（Roles and responsibility）

每一个层级都用其职能，不要低于或者高于其职能，比如丢弃掉一个客户端的应用或者类库，不是意味着丢去掉其业务层的逻辑，因为业务层是另一个层级的职责。

salesforce  层级分类如下：

 * 业务逻辑层（Business Logic Layer）
    非编码(Declarative): Formula, Validation, Workflow, Process Builder, Sharing Rules
    遍码(Coding): Apex Services, Apex Custom Actions

 * 数据处理层 （Data Access layer）
    非编码(Declarative): Data Loaders
    编码(Coding): SOQL, SOSL, Salesforce APIs

 * 数据库层 （Database Layer）
    非编码(Declarative): Custom Objects, Fields, Relationships, Rollups
    编码(Coding): Apex Triggers

在 Force.com 中使用 SOC

• 在 App 中替代或者添加另一种 UI（Replacing or adding another UI to your app），需要考虑的是有多少代码需要去重写，或者有些 UI 的端口虽然什么都没做，但是影响到了 App 的 插入（inserting），更新（updating），验证（validating）或者计算处理（calculating）的一些功能。

• 提供公用 API（Providing a public-facing API）评估一下所实现的 API 使用已有代码库的哪一部分，不要将一些动作行为的方法作为 API 基础的调用

• 通过 Batch 类来提升应用层逻辑（Scaling your application logic via Batch Apex）使用 Batch 来增大数据吞吐量，使多个用户在登录相同的 UI 页面的时候有相一致的结果

• 在 Visualforce 页面或者 Lightning Component controllers 中执行复杂的业务逻辑（Working with complex action methods in your Visualforce or Lightning Component controllers）言简意赅，使用 MVC 架构，很老生常谈的东西，在随后的章节会陆续介绍

• 让一个新的开发人员能快速上手项目的架构（Making it easy for new developers to find their way around your code base）一个新的开发人员花在熟悉代码组织架构的时间也是衡量一个项目好坏的标准之一