Project/너도나도

WAS 상 사용자 데이터 관리 WAS에서 서버의 회원의 데이터를 안전하게 관리하기 위해서 서버에서 사용자의 요청을 검증하는 과정이 필요하다고 생각했습니다. 쉽게 말해서, 서버에서 해당 사용자가 서버에 등록된 사람인지(인증)와 이 인증된 사용자가 서버 내 특정 데이터에 접근 or 특정 작업을 수행할 수 있는 권한을 가지고 있는지(인가)를 확인하는 과정은 필수적이라 판단했습니다. Session, JSON Web Token(JWT) TradeOff 인증과 인가에는 크게 Session 방식과 JWT 방식이 있음을 확인했습니다. 하지만, 이 두 가지 방식에 뭐가 더 좋다라고 판단하기 어려웠습니다. 따라서, 두 가지 방식과 특정 방식을 선택했을 때 어떤 트레이드 오프 과정을 거칠지 판단할 필요가 있겠다 생각했습니다..

Architecture 우리가 폴더 구조를 나누는 이유는 뭘까요?? 저는 각 폴더마다 고유의 역할이나 책임이 있고 이를 효율적으로 분리해놓기 위해서라고 생각합니다. 그래야 이후에 또 작업을 진행할 때 있어서 한눈에 전체 구조를 파악하기 쉽기 때문입니다! 이를 곧 아키텍처라고 일컫습니다. Architecture 는 뭘까요? : 사실 아키텍처의 정의에 대해서 정답이 존재하지 않습니다. 따라서, 이런 흐름이구나 정도로 이해해주시면 좋을 것 같습니다. - 시스템 구성 및 동작 원리를 나타낸 것 - 구성 요소 간의 관계 및 시스템 외부 환경과의 관계를 묘사하는 것 - 시스템의 전체적인 최적화를 목표로 하는 것 위 내용을 정리하면 "하나의, 서비스가 어떻게 구성되며 어떻게 동작된다"로 이해하시면 편하실 거 같습니다..

오늘은 부스에 들어갈 카테고리(인생네컷, 하루필름, 포토매틱...)를 개발하려고 합니다! 초기 로직 CategoryConstants 처음에는 이 카테고리가 부스 내에 들어가야 하고, 단순히 String 형태로 넣어주면 되지 않을까 생각해서 아래와 같이 짜보았습니다 먼저, 카테고리의 상수값들을 별도 CategoryConstants 라는 클래스에 넣어둡니다. public class CategoryConstants { public static final String LIFEFOURUCUT = "lifefourcut"; public static final String SELFLEX = "selflex"; public static final String PHOTOMATIC = "photomatic"; public..

1. 실세계 데이터 분석 요즘 저희 주변에 촬영부스가 많은 거 같지 않나요?? "이왕 부스가 나왔으면 이 데이터를 통합적으로 관리할 수 있다면 좋을텐데.." 라는 바람으로 개발을 시작했습니다!! 사용자(클라이언트)는 소셜 로그인을 통해 간편하게 회원가입과 로그인을 진행할 수 있습니다! 부스 정보에는 해당 부스의 이름을 정할 수 있는 매장 명과 카테고리(인생네컷, 하루필름 ...), 고데기 유무, 타이머 유무 정보를 담고 있습니다! 그리고, 해당 부스에는 사용자만이 흔적을 남길 수 있습니다! 여기에 대한 메모를 등록하는 거죠:) 2. 모델 개념적 설계 - 회원(Member) : 이메일, 닉네임, 로그인 유형 - 부스(Booth) : 매장 명, 카테고리, 위치, 타이머 유무, 고데기 유무, 생성 날짜 - 흔..

프로젝트 설명 - 인생네컷이나 하루필름 등 촬영 부스들을 나만의 흔적들로 기록할 수 있도록 하는 서비스!! 엔티티, RDB 설계 1. 회원 2. 부스 3. 흔적 프로젝트 목표 : 최소한의 기능이라도 데이터의 검증 과정을 철저히 다루어보기!!! - 인증 / 인가 쪽을 추가적으로 학습 및 적용 - 테스트 코드 학습 및 적용 프로젝트 계획 8월 2째주 - 프로젝트 시작 - 엔티티 설계 및 생성 8월 3째주 - 테스트 환경 분리 - 각 계층(controller, service, repository) 별 데이터 검증 8월 4째주 - 각 계층(controller, service, repository) 별 데이터 검증 ++ 엔티티 별 데이터 검증 8월 5째주 - 인증 인가 학습 및 적용 - 테스트로 데이터 검증 9월..