본문 바로가기
728x90

오프라인결제4

[신입 개발자의 두 번째 라이브러리 개발기] 도메인 특화 언어(DSL)을 만들어 보자! DDL-DSL 개발기 -2. 차후 개선 사항과 업데이트 방향- 앞선 두 편의 글에서 DDL-DSL 라이브러리의 개발 배경과 실제 구현에 대해 다루었습니다.이번 마지막 편에서는 현재 라이브러리의 한계점을 분석하고, 이를 개선하기 위한 향후 개발 방향에 대해 포스팅하려 합니다.현재 라이브러리의 한계점1. 제한적인 DDL 지원현재 DDL-DSL은 CREATE TABLE 문만을 지원합니다.실제 데이터베이스 운영 환경에서는 테이블 생성 외에도 다양한 DDL 작업이 필요합니다:테이블 구조 변경 (ALTER TABLE)테이블 삭제 (DROP TABLE)인덱스 관리 (CREATE/DROP INDEX)뷰 관리 (CREATE/ALTER/DROP VIEW)이러한 제한은 실제 프로덕션 환경에서 라이브러리의 활용도를 제한하는 요인이 됩니다.2. 스키마 변경 관리의 부재데이터베이스 스키마는.. 2024. 12. 1.
[신입 개발자의 두 번째 라이브러리 개발기] 도메인 특화 언어(DSL)을 만들어 보자! DDL-DSL 개발기 -1. 구현- 이번 편에서는 DDL-DSL의 실제 구현에 대해 다루겠습니다.라이브러리의 핵심 개념우리가 일반적으로 데이터베이스 테이블을 생성할 때는 SQL DDL을 직접 작성합니다.예를 들어, 사용자 테이블을 만들기 위해서는 다음과 같은 SQL을 작성해야 합니다:CREATE TABLE IF NOT EXISTS users ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, email TEXT NOT NULL UNIQUE, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP);이러한 SQL 작성 방식은 여러 가지 문제를 가지고 있습니다.특히 여러 데이터베이스를 지원해야 할 때, 각 데이터베이스마다 다.. 2024. 12. 1.
[신입 개발자의 두 번째 라이브러리 개발기] 도메인 특화 언어(DSL)을 만들어 보자! DDL-DSL 개발기 -0. 개발 목적과 구상- 개발 배경이번에 저희 회사에서 멀티플랫폼을 지원하는 POS를 개발하게 되었는데요.IOS를 제외한 Android와 Windows 플랫폼을 지원하는게 저희의 목표입니다.저는 이번 프로젝트 에서 아키텍쳐 설계부터 프로젝트 환경 설정, 멀티플랫폼을 지원할 수 있도록 도와주는 사내 라이브러리 개발 등을 맡게 되었습니다.일단 저희 회사가 당면한 과제는 크게 네 가지 였습니다.기존의 기술 스택을 유지해야 한다. (UI: React, Business Layer: Kotlin)다양한 RDBMS를 지원해야 한다.플랫폼 별 다양한 Van사 결제 모듈과, 다양한 회사의 프린터 기종을 지원해야 한다.메타 데이터 수정을 통해 위의 결제 모듈과 프린터 기종을 편하게 바꿀 수 있어야 한다.그 중 첫 번째 문제인 '기존의 기술 스택을.. 2024. 12. 1.
[신입 개발자의 '작디 작고 작디 작고 자그만' 첫 라이브러리 제작기] 4. Bridge-Api 데코레이터 패턴을 활용한 인터셉터 구현 안녕하세요.업무가 많다는 핑계로 항상 기술 블로그 쓰기를 미루는 게으름을 이기고 오랜만에, 라이브러리 제작기를 쓰려고 합니다.라이브러리를 제작한지 벌써 6개월이 지났는데, 이제서야 마지막 포스팅을 하게 되네요.그 동안 정말 많은 일이 있었습니다.최근 멀티플랫폼 POS를 개발하는 프로젝트에서 이제 갓 1년차가 된 저에게 벌써 과분하게도, 그리고 책임이 막중하게도, 아키텍쳐를 설계해야 하는 아키텍트의 역할이 주어졌습니다.POS, KIOSK 등을 위시한 오프라인 결제 솔루션은 그, 특성상 다양한 소프트웨어적, 하드웨어적 외부 세계(ex. 다양한 van사 결제 모듈과 프린터 등)에 의존하게 됩니다.헌데, 기존의 레거시 아키텍쳐(컨트롤, 서비스, 영속성 레이어로 구성된 일반적인 삼 계층 아키텍쳐)로는 다양한 외부.. 2024. 12. 1.
728x90

티스토리툴바