面向方面的思考角度是水平分解系统。将系统中类似的关注点抽取出关注面来单独考虑，同时兼并的考虑如何或者以怎样的方式植入系统。
那么系统中对该关注面就只是按照约定配置应用了。
关注面与关注面之间并不会存在关系，即它们之间不会存在包含与被包含的关系。
面向方面事例：权限功能，就这个关注面而言，我们需要考虑如何控制用户与此所操作的资源，即用户的权限列表中是否包含资源的调用？
数据表字段的查看和操作？之后，我们在具体思考权限将如何被应用或者植入系统。
如：一个URL的权限控制应该在Controller被调用之前，一个对数据表的查询控制应该在拼接查询条件时自动加入过滤条件，
一个UI界面显示的控制应该在界面渲染后自动移除或者屏蔽指定按钮、列表项等。
面向方面(AOP)在大型项目中应用的思考：
定义合理的关注点，以及关注点的粒度问题？
粒度越细即看起来好像是单纯的把一块代码摘出来放到另一个共用地方，这很难看出AOP的好处。
粒度越粗即表示AOP代码必须依赖于公共模式的总结，这样的公共模式需要花功夫去定义。可能会编码产生更多的规则限制
（如：编码需应用AOP的新代码或者阻止AOP应用的新代码，他们都需要知道复杂而公用的关注点定义，以达到加入或阻止加入AOP的效果）。
面向方面的分析与设计需要完善：
- 怎样从具体需求中定位横切的关注点；这样的定义一定不是来自于简单的基于名字的原则。例如：Log在所有的软件项目中都是横切关注点吗？如果我们软件开发的对象类似IBM WebSphere这样的J2EE应用服务器，那么事务（Transaction）还是横切关注点吗？
- 怎样合理的控制方面的粒度？从设计阶段的横切关注点到实现阶段的方面，怎样平滑的过渡？我们经常碰到的问题是，在实现阶段，方面之间仍然有相互依赖性的问题，怎样才能在分析阶段就尽量避免此问题？
- 关注点的模型表达方式，我们通过怎样的标准形式来表达关注点，关注点之间的关系，以及横切关注点与主逻辑之间的关系？
- 这样的横切关注点分析是可以重复、可验证的吗？有没有可行的通用方法学来帮助我们使得横切关注点的识别与规范成为可控的过程？
使用文档尽可能的描述或者让维护人员了解AOP都是一个不太实际的想法。
所以，我认为AOP不应该被应用于系统的业务逻辑实现，而应该尽量使AOP变成一种与业务逻辑无关的服务。
这种与业务逻辑无关的系统服务，通常来将，需维护的可能性不高，也不影响系统业务的新增和修改，因为系统业务逻辑根本就不需要关注它。