코드카타
1. 수박수박수박수~
홀수일때 수, 짝수일때 박
class Solution {
public String solution(int n) {
StringBuilder sb = new StringBuilder("수");
for(int i = 0; i < n-1; i++) {
sb.append(i%2==0 ? "박" : "수");
}
return sb.toString();
}
}와 이번 문제는 5분만에 풀었다! 코드카타를 매일 하니 코딩 감이 다시 살아난것 같다.
2. 내적
예....? 저는 선량한 코더입니다만...
다행히 문제에 정의 식이 친절하게 주어져있었다.
a와 b의 내적은
a[0]*b[0] + a[1]*b[1] + ... + a[n-1]*b[n-1]
class Solution {
public int solution(int[] a, int[] b) {
int answer = 0;
for(int i = 0; i < a.length; i++) {
answer += a[i]*b[i];
}
return answer;
}
}Github 오류..? 으잉..?
오늘자 코드카타를 커밋했는데 이상한 오류가 났다.. 코드카타 레포에 푸시를 했는데 이 상태로 로딩이 안되는것이었다.
🤯 프로젝트 때 이러면 안되는데....!
해서 원인을 파악해봤는데, 폴더명에 ?를 쓴것이 화근이었나 추측해봤다.
태생이 윈도우 유저라 이런일이😅
+ 오늘 학습 종료 후에 봤는데 아무 조치 없어도 다시 제대로 보였다. 뭘까..?🤔
배달 주문 관리 프로젝트
논중화물 : 지역을 어떻게 저장할 것인가
오늘 오전 회의 시작부터 바로 우리 팀의 논중화물이었던 지역 도메인 설계에 대한 이야기를 나누었다.
- 선택한 지역의 가게를 보여주기 위한 카테고리 분류 용도의 지역
region테이블 - 고객이 가진 배달지 주소
user_address테이블
로 목적에 따라 분리하기로 했다.
[지역] 카테고리 분류 (region 테이블)
도로명주소 vs 옛 주소
도로명주소는 xx구 단위까지가 공통분모가 된다.
하지만 카테고리를 분류하기 위해 사용하기엔 너무 큰 단위가 되는 것 같아
옛 주소는 xx동 단위까지 공통 분모가 있기 때문에 카테고리분류에 용이하다.
카테고리 분류에 xx동 단위가 있는 옛 주소 체계를 사용하기로 했다.
[배송지] (user_address 테이블)
결국 어차피 우리가 만들게 될 앱이 배달 서비스이기 때문에 지도 API확장을 염두에 두고 배달지 주소와 store에 각각 좌표까지 저장하고 (region의 경우 가게의 분류용도로만 사용-좌표정보없음)
이후에 배달 도메인이 추가되었을 때
좌표를 활용한 근방 거리 계산에도 활용 가능하도록 열린 구조를 가지고 있도록 했다.
야호! YAGNI : You Aren’t Gonna Need It 법칙 위배하기!
MSA 확장 여부를 생각해서 API 엔드포인트 설계하기
예전엔 두 도메인에 걸친 기능이 있으면
아무 생각없이 “먼저 호출하는 서비스” 기준으로 컨트롤러를 두고
그 컨트롤러 기준으로 URL을 만들었다.
/orders/{storeId}/그래서 이런 엔드포인트 방식에 대해 별다른 생각이 없었다.
“가게의 주문을 조회하니까 store 밑에 두는 게 맞지 않나?”라는 생각뿐 이었다.
하지만 Order는 단지 storeId를 foreign key로 가질 뿐 Store의 하위 엔티티가 아닌 독립적인 도메인 모델이지만, storeId가 orders의 하위 리소스처럼 보이게 한다.
그런데 만약 MSA 확장으로 Store Service와 Order Service를 분리한다면?
Store 서비스 소속인지 Order 서비스 소속인지 애매해지는 도메인 분리 문제가 생긴다.
결국에 MSA를 생각해보면 요청을 받아 Store를 거쳐 결국 반환하게 될 주문 리소스 더 직접적으로 관리하는 Oreder 쪽이 들고 있는게 맞기 때문에 도메인을 확실하게 표시하는 아래 방법으로 수정했다.
/orders?store-id=&page=&size=&criteria=너무 우리 서비스 자체에서만 하게 생각하지말고, 다른 구조의, 확장될 경우의 서비스는 어떨까? 생각을 해보고 설계와 기술 적용에 있어 시야를 넓혀서 봐야겠다는 생각을 했다.
통계
현재 우리 서비스 구상에서는 가게 평균 평점이 통계 쪽에 해당하게 되는데,
해당 리소스가 실시간성에 민감한 음식점 별점이 매출에 직결되어 사장님이 별점 0.0001점에 울고 웃는 서비스라 생각하기 때문에 조회에 유리하게 설계 할 것인지,
고객 입장에서 4.5점 이상의 고점대 / 2점 이하의 저점대 두 가지만 추상적 의미만 두고 음식점을 고르게 된다면 즉시 리뷰 통계를 내지 않아도 될 것인지 서비스를 정의하는것에 따라 다르다.
오늘의 과제: CI/CD 구성도 그리기
