[project]- thirdTool

문화 설명서 바운더리 및 Facade 설명서입니다.

믄화설명 0.0.1 버전 정리 https://velog.io/@js-kim-arc/third-tool-%EA%B4%80%EB%A0%A8-%EB%AC%B8%ED%99%94-%EC%84%A4%EB%AA%85-0.01ver-2%ED%8E%B8 > 믄화설명 0.0.2 버전

💚 third tool의 장기 컨셉연필, 공책에 이은 장기기억 학습의 세 번째 도구가 되어보자.장기기억, 그리고 경험의 중요성.무한한 메모리인 장기기억을 경험해보자.💚 third tool이 제공하고 싶었던 것들 (When & How)스케줄링 타이밍학습을 할 때마다

the third tool부제: 연필, 공책 그리고 ‘망각 방지를 위한 제3의 도구’우리는 방대한 데이터 속에서도 잊지 않도록 돕는 ‘기억 백신’을 개발하고 있습니다.필요성과 배경정보는 매일 기하급수적으로 쌓이지만, 우리는 여전히 연필과 공책에 머무른 도구를 사용하고

ㅇㅇㅇㅇ

회고록 관련 바운더리 입니다.

컨셉은 우리의 모든 결정 기준이자 나침반입니다.초기 컨셉은 모든 기능, 흐름, 우선순위의 기준이 됩니다.나중에 기능을 확장하거나 성능을 조정할 때도, 컨셉이 판단 기준이 됩니다.예: 단순함(simple)을 추구하는 컨셉이라면, 복잡한 설정 기능은 제외할 수 있습니다.기

(현재 글 작성 중입니다)

초기 Card 도메인 설계에서는 카드의 상태뿐 아니라 초기화, 복습 결과 처리, 주기 조정 등 여러 3day context와 permanent에 대해서 한번에 처리해야하는 문제가 발생 → 오브젝트 사상 하에 문제가 된다고 판단 카드를 생성하고 초기화하는 과정에서 Car

처음 프로젝트를 시작할 당시, 도메인 주도 설계(DDD)의 개념에 영향을 받아 설계를 시작했습니다. 도메인 간의 직접적인 연관관계 매핑을 피하고, 모든 연관 객체는 ID 값을 통해 직접 조회하는 방식으로 설계했습니다. 이는 도메인 간의 결합도를 낮추고, 각 도메인을 독

(https://velog.velcdn.com/images/js-kim-arc/post/e6da7365-9318-4a65-8fa2-903b918be6fb/image.jpg)초기에 설정한 컨셉은 앞으로의 모든 기획, 기능 선택, 개발 방향의 우선순위를 결정하는

third tool의 해결하고 싶은 problem -solution개개인들은 원하는 영역에서 성장하고 싶고, 그 성장을 통해 더 큰 목표를 그리고 싶어한다.근데 여러 문화적 특성에 의해서( 이를 테면 중간고사, 기말고사 문화등 특정한 영역을 오랫동안 경험하면서 쌓아나갈

프로젝트에도 맞춤형 애자일이 필요하다고 느낀 이유( - 1. 현재 상황의 문제( - 2. 왜 이런 고민이 생겼는가( - 3. 애자일에 대한 추가 회고( - 4. 애자일의 이상적인 개인 맞춤형 방향에 대한 생각( - 4-1. 개인 맞춤형 인터페이스 — 자기 조직

Part 1. 왜 바꿨는가 — Card 시스템을 고쳐야 했던 배경1\. 기존 시스템이 잘 작동하던 이유 — Score 기반의 장점(> 2. 문제 ① 개인화의 한계 — 알고리즘으로 메울 수 없는 간극(> 3. 문제 ② UX의 한계 — 중요한 것이 눈에 안 보인다(> 4.

문제는 방식이 아니라, 받아들이는 사람의 속도였다(- 팀원은 기능이 아니라, 관성을 가진 사람이다(- 중요한 것은 ‘새로움’이 아니라 ‘익숙한 새로움’이었다(- 앞으로는 이렇게 해보고 싶다(- 마무리(팀 프로젝트, 도메인 팀의 경험을 거치면서 점점 강하게 느끼게 된 것

1\. 왜 이 비교를 하게 되었는가(- 2. A 방식: BusinessException 하나로 통일하는 방식( - A의 특징( - A의 장점( - A의 단점( - A가 잘 맞는 상황(- 3. B 방식: 도메인별 예외 클래스로 분리하는 방식( - B의 특징(

1\. 코드는 개발자(사람)가 읽으라고 만들어진 것이다.(- 2. 패키지 나누기 = 코드의 정보 조직화(정보 조직화체계의 시작)(- 3. 사고의 depth 줄이기 = 레이어를 줄이는 것이 아니라, 추론의 단계를 줄이는 것(- 4. 부정어 줄이기 = 뇌가 한 번 더 뒤집

먼저 짚고 가자 — Test Double의 종류(- Classist와 Mockist — 두 철학의 차이(- Case A — 순수 클래스로 Card 도메인을 테스트해야만 했던 이유(- Case B — Mock을 도입해봤더니 생긴 트레이드오프(- 두 접근의 트레이드오프 정

N+1 문제 — 가장 먼저 확인하는 것(2. Pagination — 전체 조회 차단(3. Projection — 필요한 컬럼만 조회(4. 읽기 전용 트랜잭션 분리(5. Bulk Insert / Update(6. 캐싱 계층 도입 순서(7. 비동기 처리 — 핵심 로직과 부

1\. 문제 인식: 왜 캐시가 필요했나( - 속도 격차 문제 (Speed Gap)( - 어떤 데이터가 문제였나(- 2. 첫 번째 선택: 왜 Redis가 아닌 Caffeine이었나(이게 중요하다.)( - 바로 Redis를 도입하지 않은 이유( - 순차적 검증의 원

"코드는 Git으로 관리하면서, 왜 DB 스키마는 기억에 의존하고 있었을까?"Spring Boot 프로젝트를 처음 시작할 때, 대부분의 개발자는 application.yml에 이 한 줄을 아무 고민 없이 추가한다.토이 프로젝트 수준에서는 이게 사실 최고의 선택처럼 느껴

ThirdTool 프로젝트에서 CardRepository, CardRepositoryAdapter, CardRepositoryCustom, CardJpaRepositoryImpl 4계층 구조를 채택한 배경과, 단순한 JpaRepository 직접 주입 방식과의 트레이드

이 글은 개인 프로젝트 Third Tool(Cornell Notes 기반 학습 카드 시스템)에 Spring 애플리케이션 이벤트를 도입하면서 겪은 고민의 흔적입니다."왜 이벤트를 써야 하는가"보다 "이 프로젝트의 어느 지점에 이벤트가 필요했는가" 에 집중했습니다.도입 전

들어가며(- 기존 구조의 한계(- 설계 결정 — Card와 CardStatusHistory의 책임 분리(- 도메인 모델 — CardStatusHistory(- CardStatusHistoryAppender — 이력 기록 전담 도메인 서비스 - 도메인 서비스의 활용(-

시작은 단순했다(- Deck을 추가했을 때(- Review가 붙으면서 확신이 생겼다(- 문제를 테스트로 확인해봤다(- 중첩 클래스로 바꿔봤다(- 테스트를 다시 작성했다(- 파일 크기 문제는 분리 기준으로 해결했다(- 바꾸고 나서 달라진 것(- 정리(Third Tool

Card와 ReviewSession을 왜 나눴는가, 그리고 그 대가는 무엇인가도메인 트레이드오프 기록(- 도메인 구조 한눈에 보기(- 장점( - 1. 관심사가 명확하게 분리된다( - 2. 같은 Card를 여러 세션에서 독립적으로 다룰 수 있다( - 3. CardR

ThirdTool을 개발하면서내린 설계 결정 중 하나가CascadeType.REMOVE와 orphanRemoval을 제거하는 것이었다.이유는 명확했다. Soft Delete 구조에서 JPA의 물리 삭제 캐스케이드는오히려 독이 된다. orphanRemoval = true

처음엔 그냥 만들었다(- 흔들리기 시작한 순간들(- 자각의 과정 — 4축이라는 언어를 얻다(- 그래서 문서를 쓰기 시작했다(- 문서를 관리하면서 달라진 것들(- 아직 남은 것들(- 마치며( ThirdTool을 개발하면서 처음으로 테이블이 "살아있는 것"처럼 느껴졌다.