상품 엔티티 개발(비즈니스 로직 추가)
상품(Item) domain 코드 작성(비즈니스 로직 추가)
@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "dtype")
@Getter @Setter
public abstract class Item {
@Id
@GeneratedValue
@Column(name = "item_id")
private Long id;
private int price;
private String name;
private int stockQuantity;
@ManyToMany(mappedBy = "items")
private List<Category> categories = new ArrayList<>();
//===비즈니스 로직==//
/**
* stock 증가
*/
public void addStock(int quantity){
this.stockQuantity += quantity;
}
/**
* stock 감소
*/
public void removeStock(int quantity){
int restStock = this.stockQuantity - quantity;
if(restStock < 0){
throw new NotEnoughStockException("need more stock");
}
this.stockQuantity = restStock;
}
}
Java
복사
실무에서는 @Setter를 제거하는게 좋다. 예를들어 재고(stock)의 경우에도 Setter를 통해 변경하는것이 아니라 별도의 메서드(addStock(), removeStock())을 통해 수정도메인 주도 설계(DDD)를 한다고 할 때 비즈니스 로직은 엔티티 안에 있는것이 응집도를 높힐 수 있다.(= 객체지향 설계)상품 리포지토리 개발
@Repository
@RequiredArgsConstructor
public class ItemRepository {
private final EntityManager em;
public void save(Item item){
if(item.getId() == null){// id가 없을 경우 새로운 객체이기에 persist해준다
em.persist(item);
} else {//id가 있을 경우 이미 db에서 관리되고 있는 객체이기에 merge로 업데이트 해 준다.
em.merge(item);
}
}
public Item findOne(Long id){
return em.find(Item.class, id);
}
public List<Item> findAll(){
return em.createQuery("select i from Item i", Item.class).getResultList();
}
}
Java
복사
상품 서비스 개발
@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class ItemService {
private final ItemRepository itemRepository;
@Transactional
public void saveItem(Item item){
itemRepository.save(item);
}
public List<Item> findItems(){
return itemRepository.findAll();
}
public Item findOne(Long itemId){
return itemRepository.findOne(itemId);
}
}
Java
복사
