标签：
之前写的感觉有点乱，把架构的设计图先放上来吧，对照着说。
CAMCOCO架构能够支持的模型：
1、B/S程序，比如CRM什么的，和访问普通网站没什么区别，都是从WEB服务器上进行操作；
2、APP的服务器端程序。APP可以是原生的，也可以是HTML5的。APP都通过WEB服务器获取REST数据进行访问，保护SOA的安全性；
3、WINFORM程序的服务器端；
从设计图上可以看出，老胡把客户端（使用场景）分为了三类：
1、不可信远程客户端：意思是可以被任何用户使用的，我们无法确保用户不会通过URL欺骗、COOKIE欺骗等等非法访问的情况，SOA服务的访问需要一个secrtKey，这个秘钥是不能被客户端掌握的，这种情况下，这类不可信客户端只能通过WEB服务来作为跳板访问SOA，而SOA的秘钥则保持在WEB服务里，不直接交给客户端。
2、可信任的远程客户端：在局部范围内使用的一些场景，用户身份和安全性是可以得到保证的，他们不会进行各种欺骗或尝试破解获得SOA秘钥。那么他们可以直接访问SOA服务进行操作。
3、可信任的本地客户端：有一些本地化的服务，比如我们引入了消息中间件后，需要做一些消息队列处理的服务时，就可以跨过SOA直接访问业务层了。
WEB服务和SOA服务的集群化
集群化是一个比较高大上的名词，其实老胡就是把各种服务给分解开来，从功能模块级就开始进行解耦。
例如一个CRM里，老胡将功能系统进行拆分：
WEB集群
1、框架WEB： framework.camcoco.com
2、身份验证WEB服务：passport.camcoco.com
3、组织架构管理WEB服务：org.camcoco.com
4、客户管理WEB服务：customer.camcoco.com
5、订单管理WEB服务：order.camcoco.com
6、....
SOA集群
1、身份验证SOA服务：soa_passport.camcoco.com
2、组织架构管理SOA服务：soa_org.camcoco.com
3、客户管理SOA服务：soa_customer.camcoco.com
4、订单管理SOA服务：soa_order.camcoco.com
5、...
框架WEB负责加载一个CAMCOCO的Client Framework，里面包含了一堆老胡写的JS，比如AJAX调用、场景保持及还原、数据提交验证、CSS样式等等。
其他的WEB服务都是一些轻量级的服务了，比如客户管理里面，就只做和客户相关的功能，比如客户列表、查询、新增、维护等等。
每个WEB服务后面是一个对应的SOA服务，WEB服务负责接收客户端数据然后转交给SOA进行处理。
这样拆分之后，今后老胡要做一个新项目，里面也用到组织架构、身份验证、客户管理、生产管理，那我们直接就把之前的服务调用过来，然后新做一个生产管理就行了。（当然这是理想情况，客户管理模块多半还是要修改的）
如果卖出一套程序给某家用户后，用户说客户这里我需要进行一些修改，那我们能很方便地定位到客户这个模块中，无论是从业务层开始修改还是只修改界面层，都是很方便的。同时在更新的时候，不会影响到其他功能模块的正常使用。
至于业务层，老胡设计的实体中不包含操作方法，所有的操作都是放在聚合中进行，实体只负责数据合法性验证。SO，老胡认为实体是可以交给之上任意层使用的，这样在各层间传递参数时就可以直接传递实体对象，而不需要设计复杂的接口函数将实体的各个属性分别传递下去了。
业务层里针对不同的服务包含了N多的业务单元，如上面的例子，那么里面就至少会包含CAMCOCO.Business.Customer和CAMCOCO.Business.Order，至于每个业务单元如何去设计，就根据需要了，比如你要用到消息中间件减轻压力，比如要用到IOC实现业务灵活转换。
总之，CAMCOCO设计的初衷就是：
1、每个业务都是可拆分可组合的，不同的系统可以共用尽量多的业务模块；
2、在框架允许范围内，尽量少的编写代码，且代码是尽量规范的；
3、单独业务（核心业务除外）不会影响全局系统的运行，不同业务可以交由不同人员完成，每个业务的不同层级也可以交由不同人员完成。
GO ON...
标签：
原文地址：http://www.cnblogs.com/iambluebird/p/4974077.html
