[project] - 내일배움캠프 

ㅇㅇ

1\. 들어가며(- 2. 이번 미션의 배경(- 3. 처음에는 기능이 아니라 해야 할 것의 덩어리로 보였다(- 4. 크게 만들고 싶을수록 더 잘게 나눠야 한다(- 5. Sprint 1 — 최소 운영 흐름부터 닫기(- 6. Sprint 2 — 구조를 확장하되 기존 흐름은

단순한 CRUD를 넘어, 그날 먹고 싶은 마음에 가까워지는 방향으로들어가며(> - 1. 초기 미션의 시작: 맛집 리스트 CRUD 구현(> - 2. 처음 맞닥뜨린 어려움: React와 JavaScript에 대한 낯섦(> - \[2-1 새로운 도구의 활용: Mock A

Calculator 클래스를 만들고 App에서 인스턴스를 생성했는데, 막상 main()을 보니 연산 로직이 Calculator가 아닌 App에 그대로 남아 있었다.(연산의 책임은 Calculator의 객체가 지고 io의 책임은 App이 지고 있는 상황)Calculato

커머스 플랫폼에 관리자 모드를 추가하면서문제점을 만났다. 예외 처리를 어디서, 어떻게 해야 하는가 였다.코드는 결국 동작했지만, 그 과정에서 생각보다 많은 것을 고민했다.(항상 Exception , 에러코드들을 관리하는 것은 복잡한 것 같다.)요구사항을 처음 읽었을 때

스파르타 코딩클럽 일정 관리 과제를 진행하면서,Bean Validation을 사용하지 않는 조건 하에 Schedule·Comment 서비스의 검증 로직을 어떻게 설계할지 고민했던 과정을 정리한다.과제 제약 조건은 두 가지였다.Bean Validation 사용 금지 (@

캐시가 답이 되는 상황은 분명히 존재합니다. 하지만 그게 언제인지 알려면 명확한 기준이 필요합니다. 이 글에서는 캐시 도입을 결정할 때 쓰는 4가지 조건, 4가지 부적합 케이스, 그리고 실전 도입 순서를 정리해보겠습니다\~~! 핵심 질문: "이 데이터는 얼마나 자주 읽

예비군 일정과 겹쳐서 우선 임시 페이지로 제출하겠습니다!

일당백 백오피스 프로젝트(com.ildang100.backoffice) 회고 시리즈의 첫 글.도메인: admin / customer / product / order / review (Bounded Context별 분담)담당: product 도메인 + 재고 자동화 플로우

ㅇㅇ