sungwony

대안은 무엇인가? SRP(단일 책임 원칙)와 DIP(의존성 역전 원칙) 부터 시작해보자 단일 책임 원칙 일반적 해석 하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다 실제적 정의 컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다 아키텍처에서는? 컴포넌트를 변경할 이유가 한 가지라면 어떤 다른 이유로 소프트웨어를 변경하더라도 이 컴포넌트에 대해서는 전혀 신경 쓸 필요가 없다는 것 이것은 의존성에 의해 너무도 쉽게 깨진다 부수효과에 관한 이야기 컴포넌트의 부수효과로 인해 소프트웨어를 변경하는데 더 많은 비용이 지불된다 의존성 역전 원칙 계층 간 의존성은 항상 다음 계층인 아래 방향 영속성을 변경 → 도메인도 함께 변경된다 의존성을 어떻게 제거할 수 있을까? 의존성 역전 원칙 ..

계층 구조 Q. 계층형 아키텍처의 문제점은 무엇인가? 코드에 나쁜 습관이 스며들기 쉽다 시간이 지날수록 소프트웨어를 변경하기 어렵다 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다 모든 것이 영속성 계층을 토대로 만들어진다 애플리케이션의 목적 비즈니스를 관장하는 규칙, 정책을 반영한 모델을 생성해 편의성을 높이는 것 상태(state)가 아니라 행동(behavior)을 중심으로 모델링한다 행동이 상태를 바꾸는 주체 그런데 왜? 도메인 로직이 아닌 데이터베이스를 토대로 아키텍처를 만드는가 우리는 도메인 로직을 먼저 만들어야 한다 그래야 우리가 만드는 로직을 제대로 이해했는지 확인할 수 있다 그리고 이를 기반으로 영속성 계층과 웹 계층을 만들어야 한다 ORM이 원인이다? ORM에 의해 관리되는 엔티티들은 ..

계층형(layered) 아키텍처 스타일의 단점 클린 아키텍처 육각형 아키텍처(Hexagonal Architecture) 도메인 중심 아키텍처의 장점 → 이후 육각형 아키텍처의 실습 학습 목표 계층형 아키텍처를 사용했을 때의 잠재적인 단점 아키텍처 경계를 강제하는 방법 잠재적인 지름길(?)들이 소프트웨어 아키텍처에 어떤 영향을 미칠 수 있는지 언제 어떤 스타일의 아키텍처를 사용할 것인지 아키텍처에 따른 코드 구현 아키텍처의 각 요소들을 포함하는 다양한 종류의 테스트 예제 코드 GitHub - wikibook/clean-architecture: 《만들면서 배우는 클린 아키텍처》 예제 코드 서문 클린 아키텍처 이론은 알겠지만?! → 선행 공부 했어야 하나? 클래스 간의 의존관계가 어느 정도로 허용되어야 하는지..

이 포스트는 SNU에서 제공하는 운영체제의 기초 강의를 개인 학습용으로 정리한 포스트입니다 Agenda 프로세스 개념 프로세스 스케쥴링 컨텍스트 스위칭 프로세스 생성과 종료 멀티스레딩 결론 프로세스의 개념 - 프로세스는 무엇이며 왜 필요한가? 프로세스는 원인과 결과를 귀속시키는 대상 = 프로세스는 OS상에서 프로그램을 실행시키는 기본 주체 = 런타임 시스템의 수행 주체 = CPU 등 자원을 할당 받는 주체 (OS에서 프로세스는 가장 중요한 단위다) ※ Decomposition : "복잡한 문제를 단순한 여러 개의 문제로 나누어 처리하는 방법론" => 프로세스는 수행의 주체이면서 복잡한 문제를 단순화 시킬 수 있는 주체 프로세스를 한마디로 정의하면 'Program in execution(수행중인 프로그램)..

이 포스트는 SNU에서 제공하는 운영체제의 기초 강의를 개인 학습용으로 정리한 포스트입니다 컴퓨터 시스템의 기본 요소 : CPU, Memory, I/O Device 하드웨어의 요소를 연결하는 장치 : System Bus I/O Device는 자신과 Bus간의 Controller가 존재(Controller가 CPU를 대신해서 I/O Operation을 관장) System Bus - CPU와 Memory, CPU와 I/O Device, Memory와 I/O Device간의 데이터 전송을 담당 - Data Bus - Data 정보를 전달 - Address Bus - Data의 Source와 Destination을 지정하는 것이 Address - Address 정보는 Address Bus에 의해 전달 - Bus..

이 포스트는 SNU에서 제공하는 운영체제의 기초 강의를 개인 학습용으로 정리한 포스트입니다 강의 목표 사용자를 위한 연결된 멀티미디어 서비스를 제공하는 OS의 특징을 익힌다 Phase3 : 90년대 중반 ~ 현재 인터넷이 선택이 아닌 필수로 변하였다 개인용 PC의 커다란 성능의 향상을 이루었다 멀티미디어 제공이 과거보다 매우 중요하여짐 Downloading과 Streaming Downloading은 전체 데이터를 확보한 다음에 작업을 실행할 수 있음 Streaming은 일부 데이터만을 확보하여도 작업을 실행할 수 있음 스케줄링 방식의 변화 중요한 일을 먼저 처리해주는 우선순위 기반 스케줄링에서 Continuous Media를 원활하게 처리하기 위한 Bandwidth 스케줄링으로 변화 : proporti..

이 포스트는 SNU에서 제공하는 운영체제의 기초 강의를 개인 학습용으로 정리한 포스트입니다 강의 목표 주요한 OS 기능을 배우고 실습한다 OS 내부의 상호작용을 이해한다 더 나은 소프트웨어 개발 혹은 새로운 OS 디자인에 지식을 접목한다 1. OS의 발전 과정 50년대 초반 ~ 60년대 중반 60년대 중반 ~ 90년대 중반 90년대 중반 ~ 현재 Phase1 : 50년대 초반 ~ 60년대 중반 최초의 OS 등장의 배경 하드웨어는 매우 고가의 장비이고 인건비는 상대적으로 저렴하였다 (대표적인 컴퓨터로 팬실베니아의 애니악이 존재) 값 비싼 하드웨어를 효과적으로 활용할 필요가 있었다 Operator(사람)는 다음과 같은 역할을 수행하였다 1. 사용자로부터 카드 덱을 수령 2. 카드 덱을 컴퓨터 시스템에 로딩하..

네트워크 터널링에 대해 학습하면서 간단히 정리 터널링(Tunneling) * 정의 : 데이터 스트림을 인터넷 상에서 가상의 파이를 통해 전달시키는 기술 실제로 여러 홉을 거쳐서 가야하는 목적지를 마치 터널을 파서 다음 홉에 있는것처럼 보이게 하는 기술 출발지 호스트와 목적지 호스트에서만 사용하고 그 사이에서는 사용하지 않는 프로토콜을 전송하여 양측간 통신이 가능하게끔 만들어 주기 위함. 여기에서 핵심이 되는 기술이 캡슐화이다. 캡슐화는 OSI 7 계층을 참조하여 통신을 하기 위해 하위계층에서 상위계층 데이터를 포장하는 개념이다. 즉 모든 계층의 데이터를 캡슐화하여 전송하고 데이터가 목적지에 도착한 뒤에 디캡슐화 하는 전체의 과정을 터널링이라고 부른다. 이러한 터널링은 크게 3가지의 요소로 나뉘어 진다. ..

메세지 브로커(message broker)란? 메세지 브로커(integration broker, interface engine)는 송신자(sender)와 수신자(receiver) 사이에서 메세지의 전달을 중재하는 컴퓨터 프로그램 모듈이다. 메세지 브로커는 정형화된 메세지의 교환을 통해 어플리케이션간의 소통이 이뤄지는 네트워크 엘리먼트(element)이다. 메세지 브로커의 목적, 기능, 설계 메세지 브로커는 메세지의 유효성, 전송, 라우팅을 위한 아키텍처 패턴이다. 이것은 어플리케이션 사이의 커뮤니케이션을 중재하고 어플리케이션간의 메세지 전달을 위한 상호 인식(mutual awareness)를 줄여 어플리케이션간의 결합성을 낮춘다(decoupling) 주요한 목적은 어플리케이션으로 부터 메세지를 받아 어떤..

프롤로그(Prologue) JPA와 ORM등의 기술은 스프링으로 개발을 하면서 꾸준히 들어왔던 기술이다. 개인적으로 기존에 개발을 하면서 주로 SQL을 분리시켜 관리할 수 있는 매퍼(Mapper)형 기술인 Mybatis, Ibatis 등을 주로 사용하였지만 배달의 민족을 비롯한 많은 큰 기업에서 JPA를 지속적으로 도입하는 등을 접하면서 이를 공부할 필요성을 깊이 느껴 본격적으로 공부하고 작은 지식이라도 도움이 되고자 블로그를 통해 남기고자 한다. JPA(Java Persistence API) JPA는 데이터를 저장하기위한 RDBMS와 OOP(객체 지향 프로그래밍, Object Oriented Programming) 사이에서 서로 다른 패러다임을 일치시키고 개발 생산성을 향상시키기 위해 꾸준하게 고민을 ..