类图中方法为何定义在同类中？此类实现是否合规？应放Service层吗？

先纠正代码的语法问题 #

你贴的这段Java代码不符合语法规范：普通类（public class Account）里不能定义没有方法体的抽象方法（比如public boolean addProduct(Product product);这种写法）。如果要保留这类无实现的方法，必须把Account改成抽象类（public abstract class Account）；如果是具体类，每个方法都必须编写实现逻辑。

关于这种写法的定位 #

这种把业务方法直接放在实体类（Account属于用户实体）里的设计，属于领域驱动设计(DDD)中的“富领域模型”，和你习惯的“贫血模型”是两种不同的设计思路：

• 富领域模型：实体类不仅包含属性，还封装了和自身强相关的业务逻辑（比如用户添加商品、重置密码），让实体自己管理自身行为，更贴合现实业务逻辑的语义。
• 贫血模型：实体类只有属性和简单的getter/setter，所有业务逻辑都放在Service层（比如AccountService），这是传统MVC项目里很常见的常规写法。

两者没有“常规/高层级”的高低之分，只是设计理念的差异。

把方法放在Service层是否有误？ #

完全没问题。贫血模型在大多数简单CRUD场景下非常实用，结构清晰、上手快，也是很多开发团队的主流选择。

要不要采用富领域模型，核心看项目复杂度：如果业务逻辑复杂、实体间交互频繁，富领域模型能让业务逻辑更内聚，避免Service层沦为臃肿的“上帝类”；如果只是简单的增删改查需求，贫血模型的维护成本更低。

另外补充：从类图转代码时要注意，类图里的方法如果标记为抽象，代码里要对应改成抽象类或接口；如果是具体方法，必须补充实现逻辑，不能像你贴的代码那样在普通类里留空方法签名。

内容的提问来源于stack exchange，提问作者Jack