今天有个牛人提到了这一点，我觉得很有意义。 DDD（领域驱动设计）提倡让Entity来负担业务逻辑，而不是都往Service里塞； 这样的一个好处是，某Entity相关的逻辑会集中在这个Entity类内部，也就是说。 当你要查看某块功能的代码时，你基本上都能在这个Entity类里找到。 这其实也是封装性的体现，即把某Entity自身的功能封装在Entity内部，对外只提供比较宏观的接口，Service之流不准直接干涉Entity的细节。 如果不走这条路，那你就要去Service里找； 而跟一个Entity相关的Service可能会有很多很多个，到时找起来就麻烦了。
如果你的应用App依赖了远程接口API_Real，那API_Real所处的系统里的其他接口如API_Neighbor其实也和你的应用产生了间接耦合：发布时的依赖。 比如说，API_Neighbor重新发布时，它所处的整个系统都要重新发布，也就是说API_Real在发布期间可能暂时无法服务，这就会影响你的App的运行。 一个影响更严重的例子是： 你更新了API_Real，别人更新了API_Neighbor，大家说好一起发布。结果发布时API_Neighbor出了问题，要紧急查错和修改，这个过程可能会持续一两天。那对API_Real来说，要么等着API_Neighbor修好一起上；要么在构建库里把API_Neighbor去掉，重新打包，只发布API_Real（这一般比较麻烦，而且会有点风险） 另一种对邻居的依赖是在二进制依赖时发生的。虽然你宣称只依赖了Jar包里的XXXService, 但你的同事可能会直接去调这个Jar包里的XXXDAO，以后XXXDAO的改动都可能影响到你的应用。
把核心服务隔离出来，做成独立的层次；并使它内聚于自身，而不必受到非核心的东西的干扰。它向外界提供简明的视图，并只按自己的特性和目标变化，不必屈从于其它东西的需要。 其他的东西，不再跟核心服务混杂在一起；它们只能通过依赖、组合核心服务，实现自己的目标。 代价是： 处处需要适配
还没想清楚，目前能想到的、所知道的有： 1. 不同客户端有权选择不同的版本，你不能强制每个客户都和你一起升级 2. 可以用来区别生产环境、测试环境、开发环境等，这样它们可以共享一套服务治理平台，如Maven或SOA服务治理平台
以前看到别人说通过异步可以提高性能总觉得无法理解。 如果一个业务本身是同步的，即使把系统的通信方式做成异步，发消息的系统不是还要等处理消息的系统弄完自己才能继续吗？ 总的响应时间能有什么变化？ 最近看了听了一些东西，突然明白了： 异步方式并不能直接减少单个业务的处理时间，但它可以减少无谓的阻塞，从而把浪费了的等待时间用起来，总体上提高TPS后，单个业务的处理时间也就会快起来。 比如说，你如果发一个同步请求，如果请求要持续一段时间(如长时间I/O)，那处理方就得阻塞着来等你发完； 处理方应答时，如果应答要持续一段时间，那你这个请求方也得阻塞着。这浪费太多时间了，如果改成异步就不用了： 你把请求发到队列里，发的时候对方可以处理别的事情。
1. 同步/异步 2. 主动/被动 3. 点对点/发布-订阅 4. 更多…… 可以多思考一下，这些东西对系统的性能、易部署性、开发环境的易搭建性都有影响。
http://en.wikipedia.org/wiki/Reverse_proxy Reverse Proxy(反向代理): 1. 它是一个Proxy：转发客户端的请求和服务端的响应 2. 为什么说Reverse? Forward Proxy一般是处在Client和Server之间，而Reverse Proxy则和Server放在一起，一般是同一个局域网内。比如apache httpd和tomcat就部署在一起。 作用：本质上来说，反向代理是一种“Indirection”。作为系统设计的核心理念之一，indirection可以起到很多种作用： 1. 安全： a.屏蔽Server的特性. 如果黑客不知道server是tomcat还是php,就无法采取专门针对特定服务器类型的攻击。 b.防火墙。Client无法直接访问Server，无法直接进行攻击。 2. 性能： a.一个Reverse Proxy下面可以挂多个Server，实现集群和load balancing. b.http协议相关的Cache. Apache httpd就很擅长这一点。 c.压缩response (不过很多Server自己也可以做这种事） d.替server分担一些请求，尤其是静态内容. httpd比tomcat处理静态内容的能力更高（原因不详) 3. 功能：可以干些URL重写之类的事情 4. 结构：对外提供唯一的服务入口，使proxy+多台server组成的系统在Internet上仍表现得像单台 a. 可以只用一个外部IP b. 可以只用一个域名，一个SSL证书 (如果你的域名本身可以对应多个IP，也不需要reverse proxy帮忙) 两个最流行的反向代理：Apache Httpd V.S. nginx (念作engine x) …
做初步解决方案的时候，往往只能抓住关键性需求做出一些比较粗粒度的方案。粗糙不要紧，但仍然需要可靠，即满足可行性。要做到这一点，就必须在构思方案(time bound)时，头脑快速响应，迅速地在脑子里对自己的方案进行校验。 要想快速思考，就得掌握一些常用的系统分析的模式；当一个问题点出现时，你可以自然而然地想到从哪些方面来考虑。 不知道有没有这样的模式大全。我自己能想到的有这些： 1.不要漏掉关键的名词性领域模型。通过比较细致的Use Case可以避免这种遗漏。 2.名词性模型是可以按业务来分类的，你可以迅速定位某种模型的类别，然而快速考虑一下它的核心特征是否满足你的方案。四色原型提出了一种分类办法，但我完全看不懂。我目前能想到的有： a.某些东西是静态的物品，如商品 b.某些东西代表一个动态的过程，如订单；这时你应该考虑它的时间属性，它依赖的静态物品，和它的状态转换。 c. … 3.领域之间关系应该搞清楚，是1:1, 1:m还是m:n
基于组件开发为SOA提供了一些理论基础。据说下面这两些书不错。 Component-Based Software Engineering: Putting the Pieces Together Component Software: Beyond Object-Oriented Programming Component-Based Development for Enterprise Systems" by Paul R. Allen Component-Based Software Development" by Kung-Kiu Lau 基于组件的企业级开发 by Peter Herzum, Oliver Sims
1.研究下: MySql开发的36条军规 2.淘宝技术大学放出的 java中间件 pdf 3.connanscence 研究