J2EE系统通过表现、业务、数据三层实现分层设计。
1、 表现层即客户端界面展示部分。
2、 服务层是系统面向客户端提供的各项功能与服务，体现其对外支持的能力。
3、 领域层：负责处理系统核心业务逻辑。
4、 DAO层负责数据访问，利用领域实体对数据库进行操作。
5、 上层依赖下层，且依赖不跨越层级。
6、 除表现层外，各层内部方法不得相互调用，这是开发中常见的误区。若确需调用，仅限于上层不可见的辅助性方法，如工具类方法等，应避免业务逻辑的跨层依赖，确保层次结构清晰，维护系统模块的独立性与可维护性。
7、 应从业务功能需求入手，先明确服务层需实现的功能，进而设计Service接口的方法。不应机械地从数据库表开始，依次构建DAO、Domain和Service，这种做法误解了系统分层的本质，容易导致业务逻辑与数据结构耦合过紧，影响系统的灵活性与可维护性。
8、 系统核心在于将实体划分为领域模型，据此构建数据访问层，并将操作封装为服务层接口，服务层的具体实现则依托于领域模型的相关行为与逻辑。
9、 每个接口都应具备清晰明确的职责边界。在我参与的系统开发中，常发现一种不良设计模式：系统从数据库表出发，一张表对应一个DAO，DAO对应一个Domain，再对应一个Service，最终Service的接口几乎与DAO完全一致，造成Service方法泛滥。到了表现层，前端开发人员在编写Action时，不得不频繁调用多个Service方法，导致代码冗长、逻辑混乱，可维护性极差。这种机械式的层级映射忽视了业务逻辑的抽象与整合，使得各层之间失去应有的职责划分，系统变得僵化而难以演进。合理的接口设计应围绕业务场景，避免简单地层层透传。
10、 一项领域活动通常对应一个或多个DAO来实现。一项服务可能涉及多个领域活动，例如转账业务就包含两个领域活动，分别对应两个账户的金额变动。执行这类服务需协调多个领域活动，每个活动又需操作多张数据表，调用多个DAO完成数据持久化。
11、 当前，越来越多架构师倾向于采用领域模型驱动设计，通过对系统核心领域建模，直接在上层构建Service，其下衔接领域活动层Activity，省去传统的DAO层。这种架构使设计逻辑更加清晰，职责划分更明确，提升了系统的内聚性与可维护性，开发目标也更为聚焦，有利于复杂业务的持续演进与迭代。
