于重复的数据请求，处理起来比较简单，只需要去掉冗余的请求即可。如果把对于用户请求的处理逻辑看做服务的话，那么如何设计服务以及定义服务边界就成为了影响性能的关键因素。这背后体现的是用户需求的本质，以及对时间的分片处理。这就要求服务之间关注点各自分离、边界比较清晰，能够适应横向扩展。比如采用Publish-Subscribe模式的系统是一个很好的选择，但是模式永远只是指引的方向，如何很好地应用这些模式，同样需要对业务系统进行不断的探索。一旦设计了这样的服务，不仅能够灵活支撑扩展性，也使得持续的性能优化成为可能，不仅如此，这样的服务设计，还能够帮我们灵活调整优化策略，比如采用多线程、异步、服务自治、分布式或者集中式节点扩展、灵活选择数据持久化机制等等。

处理N+1问题，更多地与业务模型以及业务上下文有关，从DDD的角度考虑这个问题，N+1问题好像不应该存在，这也说明了lazy-load对于DDD而言可能是一个坏味道。但是，解决N+1问题本身也相对比较容易，只要对相应的ORM框架有足够深入的理解以及借用SQL Tuning工具，解决大部分的性能问题。

针对报表的性能问题，仅仅依靠集中式的高性能的单数据库服务器，通过操作表进行数据读取，或者进行连接操作，或者进行映射操作，并不能满足用户对于性能的需求。尤其当有报表中存在业务逻辑时，比如用户权限控制，将使得出报表本身也变的非常复杂。因而，NoSQL以及分片和数据复制可能在这方面有更为出色的表现。

性能优化展望

性能问题是一个复杂的领域问题，解决性能问题关键是找出性能瓶颈，但是如果永远只能“东窗事发”之后进行补救还远远不够，因而在解决系统性能的道路上，需要在系统开发时就给予足够的重视，甚至在架构决策时，也应该考虑性能的需求。在今天分布式处理以及大数据技术飞速发展的大背景下，对于性能的解决，我们也许还有更多的选择。