백엔드 공부를 하며 각 서버가 state를 가지는가 ? 상태를 가지는가 ? 에 대한 고민을 해본적이 없었다.아니 사실은 state가 뭔지도 잘 몰랐다. 스프링 공부를 깊게 하게 되면서 서버는 state를 가지는것이 좋은 서버가 아니라는것을 배우게 되면서 그렇다면 여태까

아키텍처에 대한 고민 크게 UMC라는 연합동아리에서

정의 : 기존의 데이터, 소프트웨어, 운영체제(OS) 등의 시스템 환경을 손실 없이 새로운 환경이나 플랫폼으로 안전하게 옮기는 과정보통 마이그레이션은 정의에서 알 수 있듯이, 하위 계층의 구현사항이 바뀌게 될때 예를들어 Mysql 에서 Postgre 로의 이동이 일어날

Eum (이음) 개발 과정에 있어서 데모데이 이후, develop 하는 과정에 있어서 골칫거리가 하나 있었다.그것은 바로 서버비용...! 언제나 그렇듯 서버비용은 대학생 개발자에게 가장 큰 적이다.AWS 비용이 한달에 34만원 가량이나 나왔던 그 상황을 보고 우리는 당

운영체제에서 race condition이라는 상황에 대해서 들어보았다.race condition이란 둘 이상의 프로세스(또는 스레드)가 동시에 공유 자원(Shared Resource)에 접근하여 데이터를 수정할 때, 실행 순서(interleaving)에 따라 결과가

너무 느리다. 진짜 개느리다. 몇일 후 출시 예정인데, 사용자가 화병나서 사용 안할것같은 느낌이다. 어느정도냐면 이 화면에서 개 산책 동호회, 공개 동호회 테스트 이미지를 불러오는데 0.5초~1초 정도 걸린다. 출시..할 수 있을가?(😅😅😅😅) 원인분석

DDD설계가 다른 설계와 달리하는것. 즉, 관점의 차이 DDD 계층 구조 application service 응용 domain infrastructure !image.png DIP - Dipendency Inversion Principle 저 수준 모듈이 고