semtax의 개발 일지

Hexagonal Architecture 개요 이번 포스팅 에서는, 육각형 아키텍처(Hexagonal Architecture) 에 대해서 알아보고 간단한 예제를 통해 실제로 어떻게 육각형 아키텍처를 적용 하는지에 대해서도 알아보도록 하겠습니다. 계층화 없는 코드 = 스파게티 먼저 육각형 아키텍처를 설명하기 전에, 제가 첫 프로젝트를 진행했을때의 이야기를 해보겠습니다. 제가 모 기관에서 안드로이드 APK 보안취약점 분석을 수행해주는 서비스를 진행했을때, 저는 모듈화나 아키텍처에 대한 개념이 거의 없었습니다. 그래서 저는 입력값 검증 로직, 실제 비즈니스 로직, 데이터베이스 저장 로직 들을 전부 컨트롤러에 해당하는 메소드에 몰아넣어서 작성 하였습니다. 사실 맨 처음에 개발을 할때는 코드가 몇 줄 되지 않아서..

개요 ​ 이번에는, 이벤트 핸들링을 하는 디자인 패턴 중 하나인 리액터 패턴에 대해서 알아보도록 하겠습니다. ​ ​ 왜 나오게 됬는가? ​ ​ 시스템에서 여러 종류의 이벤트를 동시에 동기적으로 처리하게 될때 어떻게 해야하는지 고민을 하다 나오게 된 패턴입니다. ​ ​ 문제 상황 ​ ​ 먼저 아래와 같은 상황을 가정해보도록 하겠습니다. ​ ​ 당신이 만약 IoT 센서 데이터를 처리하는 서버를 만든다고 가정을 해봅시다. 이때 센서 데이터들은 언제 들어올지 불확실 하므로 이벤트 드리븐 기반의 서버를 작성해야 한다고 판단하였습니다. 일단 당신은, 단순하게 무한 루프를 만들고 센서 데이터에 관한 이벤트가 왔나 안왔나 폴링(이벤트가 왔나 안왔나 계속 체크하면서 이벤트가 오면 이벤트에 관한 코드를 실행하게 하기)하는..

개요 ​ 이번에는, 아키텍처 패턴 중 하나인 브로커 패턴에 대해서 알아보도록 하겠습니다. ​ ​ ​ 왜 나오게 됬는가? ​ 브로커 패턴은, 서로 다른 기종의 머신에 분산되어있는 서비스(객체 혹은 컴포넌트)간에 어떻게 협력을 잘 할지 고민하다 나온 패턴입니다. ​ 따라서, 분산 시스템이나 RPC를 구현할때 사용되는 패턴에 많이 사용됩니다. ​ ​ 문제 상황 ​ 먼저 한가지 상황을 가정 해봅시다. ​ 당신이 만약에, 대기업에서 IoT 기반의 스마트 홈 네트워크 시스템을 구축한다고 가정합시다. 그런데, 같이 참여하는 업체가 10개가 넘어가는데다, 임베디드 장비들이 전부 CPU 기종이 다르고 프로토콜도 제멋대로인 상황에 처하였습니다. 더 황당한것은, 임베디드 장비들이 교체되는 일도 빈번하고, 그에 따라 연결되는..

개요 ​ 이번에는, 생성 패턴 중 하나인 싱글톤 패턴에 대해서 알아보도록 하겠습니다. ​ ​ 왜 나오게 됬는가? ​ 싱글톤 패턴은, 여러 객체에서 데이터를 공유해서 써야하는데 단 1개만 생성해서 써야할때 어떻게 해야할까 라는 고민에서 나오게 된 패턴입니다. (OOP의 전역변수 라는 느낌으로 생각하시면 됩니다.) ​ 주로, 여러곳에서 쓰이는 설정 정보나, 다른곳에서도 공통적으로 쓰이는 데이터베이스 설정 객체와 같은 정보들을 공유할 때 사용되게 됩니다. ​ ​ 문제 상황 ​ 먼저 아래의 상황을 한번 가정 해봅시다. ​ 당신이 앱을 개발한다고 가정을 해봅시다. 그런데, 앱에 있는 여러 클래스에서 앱에서 전역으로 쓰이는 설정정보를 읽고 써야하는 상황이 닥쳤습니다. 이럴때 당신은 어떻게 하겠습니까? ​ 위와 같은..

개요 ​ 이번 포스팅에서는, 생성 패턴 중에 하나인 빌더패턴에 대해 알아보도록 하겠습니다. ​ ​ 왜 나오게 됬는가? ​ 이 패턴같은 경우, 복잡한 객체를 생성할때 초기화를 단계별(step-by-step)로 해야 할 때, 어떻게 깔끔하게 코드를 작성할 수 있을까를 고민하다 나온 패턴입니다. ​ ​ 대표적인 예로 자동차 조립, 피자 만들기가 있습니다. ​ 이제 실제 예제로 어떤 문제가 있는지 알아보도록 합시다. ​ ​ 문제 상황 ​ 먼저 피자 라는 객체를 만든다고 가정을 해봅시다. 피자에는, 올리브 토핑도 들어 갈 수 있고, 페퍼로니 토핑도 들어 갈 수 있고, 피망, 채소도 들어갈 수 있고 고기도 들어갈 수 있습니다. ​ 하지만, 저 재료들을 무조건 넣어야 되는게 아니고, 선택적으로 넣을 수 있습니다. ​..

개요 일정 규모 이상의 프로젝트를 진행할때에 있어서 모듈간 의존성이나, 코드의 품질을 관리하는것은 매우 중요하다. 그래서 많은 사람들(특히 소프트웨어 공학을 전공한 석,박사들)이 어떤 코드가 나쁜 품질의 코드인지 좋은 품질의 코드인지를 구분하는 많은 기준들을 만들어 냈다. 보통 아래와 같은 기준들이 존재 한다. Instability 해당 패키지 또는 모듈이 얼마나 바꾸기 힘든지를 나타내는 지표이다(보통 다른곳에서 많이 쓰고있는 모듈들이 바꾸기 힘드므로.) N(Efferent Coupling) / (N(Afferent Coupling) + N(Efferent Coupling)) 로 계산한다. Efferent Coupling : 다른곳에서 해당 패키지를 사용하고 있다는 의미 Afferent Coupling ..