엘런 멘토님 의견
객체지향 이라면 controller, service는 제외해야 한다.
- 패키지 구조
1. 모델 단위
2. 레이어 단위
각각의 장단점이 있다. 나눈다고 해서 드라마틱한 효과는 없다.
대규모는 레이어 단위가 더 편할 수 있다.(한 모델에 파일 100개 있으면 끔찍..’s)
소규모는 모델 단위로 나누는게 좋을 것 같다.
패키지 구조는 팀원들과 상의해서 .. 하는게 best
배포 단위 (multi-module) → 의존성을 완전히 배제하는 방법(빌드툴) → 단방향을 최대한 유지할 수
도메인, 컨트롤러, 서비스
domain
- Order
- Item
- Coffee
- Reciept
- MenuInventories
- payment
- pay<<interface>>
- Card
- Cash
dto
- ItemsAndRecieptDto
service →
- baristar →
controller
→ congestion,- cashier →
- Main.java (Customer) → 협력의 시작의 용도는 아니다.
의도한바
command Line
- main() 함수 안에서 → 커피를 주문하다.
- 주문을 하시겠습니까 → yes
- 어떤 커피를 주문할 건지 → item들을 입력해서 order
연우님
- 애매한데 잘 모르겠다.
진형님
- 객체지향과는 조금 멀지 않나.
- casher , baristar가 클래스 다이어그램에서는 객체로 표현되었는데 controller,service가 되니 조금 이전과는 맞지 않는 것 같다.
- 모델은 모델로서 행하다
- customer가 없는게 살짝 의문이다.
용훈님
- 무대와 엑터의 구분이 없는 것 같다.
- main이 too much하다.