Taeguk's Blog

최근에 NDC 에서 발표했던 발표 영상과 자료를 블로그에도 올립니다..

안녕하세요~ 오늘은 Monad Transformer 에 대해서 포스팅해보려고 합니다 ㅎㅎ Monad Transformer 란? 자, 다음과 같이 간단한 코드가 있습니다. case class User ( id : String , bestFriendId : String ) def getUser ( userId : String ) : Future [ Option [ User ] ] = ? ? ? def getBestFriendOfUser ( userId : String ) : Future [ Option [ User ] ] = for { userOpt <- getUser ( userId ) bestFriendIdOpt = userOpt . map ( _ . bestFriendId ) bestFriendOpt <- bestFriendIdOpt match { case Some ( bestFriendId ) => getUser ( bestFriendId ) case None => Future . successful ( None ) } } yield bestFriendOpt getBestFriendOfUser 함수를 보면 Future 와 Option 이 함께 쓰이고 있는 것을 볼 수 있습니다. User 가 Option 과 Future 에 의해 2중으로 감싸져있기 때문에 실제 User 값에 대해 뭔가 연산을 수행하려면 상당히 성가시고 가독성도 떨어지게 됩니다. 결국 문제가 되는 부분은 “2중으로 감싸져있다” 는 점입니다. 즉, Future 와 Option 을 하나로 합친 타입을

안녕하세요! 오늘은 스칼라 초심자를 대상으로 Tail Recursion (꼬리 재귀) 와 Trampoline 에 대해 포스팅하려고 합니다. 함수형 프로그래밍이나 모나드를 몰라도 이해할 수 있도록 노력해봤습니다~~ 간단하게 1부터 n 까지 더해주는 함수를 아래와 같이 작성한 뒤 실행 해봅시다. 스택오버플로우 에러가 뜨는 것을 확인할 수 있습니다. def unsafeSum ( n : Int ) : Int = if ( n == 1 ) 1 else n + unsafeSum ( n - 1 ) println ( s "sum = ${unsafeSum(100000)}" ) // 실행결과 // Exception in thread "main" java.lang.StackOverflowError // at dogs.MyApp$.unsafeSum(Main.scala:8) // at dogs.MyApp$.unsafeSum(Main.scala:8) // at dogs.MyApp$.unsafeSum(Main.scala:8) // at dogs.MyApp$.unsafeSum(Main.scala:8) 이번에는 아래와 같이 함수를 수정한 뒤에 실행 해봅시다. 스택오버플로우 없이 잘 동작하는 것을 확인할 수 있습니다. def safeSum ( n : Int , acc : Int ) : Int = if ( n == 0 ) acc else safeSum ( n - 1 , n + acc ) println ( s "sum = ${safeSum(100000, 0)}" ) // 실행결과 // sum = 705082704 대체 무슨 차이점 때문일까요? unsafeSum(5) 가 값을 반환하려면 일단 unsafeSum(4) 를 호출해서 결과를 얻은다음에 그 결과에 5 를 더해야합니다.

오늘은 제가 가장 좋아하는 소프트웨어 설계 기법인 Aggregate Pattern 에 대해서 소개해드리겠습니다! Aggregate Pattern 이란? Aggregate Pattern 은 Eric Evans 의 Domain-Driven Design 에서 소개된 설계 패턴으로써 아주 강력하고 scalable 한 설계 지침을 제공합니다. Aggregate 를 제대로 설명하기 위해서는 Entity 등과 같은 DDD 의 다른 개념들도 같이 설명이 필요한데요. 이 글의 목적이 DDD 가 아니고 DDD 및 Aggregate 에 대한 개념적인 설명들은 인터넷에 많이 있으므로 이 글에서는 Aggregate Pattern 에 대한 통찰들을 전달하는데 집중하겠습니다. Aggregate 를 쉽게 말하자면 그냥 이름 그대로 연관 객체들의 묶음입니다. 즉, Aggregate 를 설계하는 것은 서로 연관된 객체들을 하나의 Aggregate 안으로 묶는다는 것이죠. 여기까지 말하면 사실 Aggregate 는 별로 의미가 없습니다. Aggregate 는 몇 가지 특징 및 제약사항들 을 가짐으로써 힘을 발휘하게 됩니다. Aggregate 는 내부의 도메인 객체들을 완전히 독점 소유합니다. 이게 무슨 말이냐면, 객체들은 오직 하나의 Aggregate 에만 속하게 되고 객체들의 lifetime 은 속해있는 Aggregate 의 lifetime 에 제한된다는 것입니다. (Aggregate 가 삭제되면 내부의 객체들도 같이 삭제됩니다.) Aggregate 는 항상 내부 객체들의 불변성을 강제해야만 합니다. 무슨 말인고 하니 Aggregate 내부는 항상 비지니스 룰에 부합하는 상태를 유지해야한다는 뜻입니다. Aggregate 각각이 transaction boundary 가 됩니다. 즉 하나의 트랜잭션에서는 하나의 Aggregate 만 변경할 수 있습니다. 여러 개의 Aggregate 들을 한 트랜잭션으로 변경하는 것은 불가능합니다. Aggregate 를 설계할 때는 위의

안녕하세요! 제 이름은 taeguk 입니다~ ( 갑자기? ) 오늘은 가벼운 주제로 포스팅해보려고 합니다. 다들 github 많이 사용하실텐데요~ 오늘은 제가 사용하는 크롬 확장 프로그램들중에서 github 를 사용할 때 아주 유용한 것들을 소개해드리는 시간을 가져보려고 합니다^^ 1. Refined Github 이거는 진짜 필수입니다!! 이 확장 프로그램은 github 웹페이지 자체를 아주 화끈하게(?) 바꿔버립니다! 정말 UI 가 더 예쁘고 사용성있게 변경되는데요. 그 외에도 다양한 기능들을 추가로 제공해줍니다. 예를 들면 다음과 같습니다. 아래 사진은 익스텐션 적용 전 & 후 인데요. 적용 후에 UI 가 더 정돈되는걸 볼 수 있습니다. 뿐만아니라 OpenAll 과 같은 버튼을 추가적으로 지원하는 것을 볼 수 있습니다. 그 외에도 제공해주는 기능이 무척 많은데요! 자세한 것은 깃허브 를 참고하시기 바랍니다. 참고로 오픈소스계의 유명인사(?) Sindre Sorhus 님이 개발하셨습니다! 짱짱bb 2. Octotree 이건 github 상에서 코드베이스를 분석할 때 매우 유용한 확장 프로그램입니다. 보통 github 에서 소스파일을 왔다갔다 하면서 코드를 보기가 매우 불편한데요. Octotree 를 사용하면 마치 IDE 를 사용하는 것처럼 편하게 여러 개의 소스파일들을 드나들면서 코드 분석이 가능합니다. 위 사진에서 볼수있듯이 브라우저의 왼편에 navigator 가 생겨서 그걸 이용해서 편하게 원하는 소스파일을 찾아갈 수 있습니다. 또 추가적으로 특히나 좋은 것은 PR 의 diff 를 확인할때 유용하게 활용이 가능하다는 것입니다. 이 경우에는 변경된 파일들에 대해서만 트리가 구성되서 코드리뷰시 아주 유용하게 활용이 가능합니다 :) 근데 octotree 를 사용하시다보면 위와 같은 에러를 볼 때가 있을텐데요. 이는 octotree 가 내부적으로 사용하는 Github API 에서 API 횟수 제한을 두고 있기 때문에

안녕하세요~ 오늘은 akka 의 새로운 인터페이스 (API) 인 akka typed 에 대해서 소개시켜드리는 시간을 가져볼까 합니다! Akka 및 액터 모델에 대한 기본적인 내용은 이미 알고 있다고 가정하며 scala 를 기반으로 설명하겠습니다. 기존 akka 에서의 문제점 akka 는 훌륭한 프레임워크이지만 인터페이스 (API) 상으로 아쉬운 부분들이 있습니다. class EchoStringActor extends Actor { def receive = { case str : String => sender ( ) ! str case _ => sender ( ) ! "Unexpected message" } } 메세지의 타입이 Any 입니다. Java/scala 는 정적 타이핑 언어로서 컴파일타임에 타입시스템을 이용해 많은 오류를 사전에 차단시켜줍니다. 그러나 akka 의 인터페이스에서는 액터가 받는 메세지의 타입이 Any 입니다. 따라서 정적 타이핑의 이점을 전혀 누릴수가 없습니다. 만약에 개발자가 실수로 특정 타입의 메세지를 처리하는 것을 깜박하더라도 컴파일 에러가 나지 않습니다. 액터들이 어떤 메세지를 서로 주고받는지가 명확하게 드러나지 않아서 저는 전체 액터 시스템을 분석하고 유지보수할 때 상당히 복잡하고 머리속에 정리가 잘 안된다는 느낌을 많이 받았습니다. 함수형 스타일이 아닙니다. Actor 를 정의하기위해서는 Actor 클래스를 상속받아서 새로운 클래스를 만들어줘야 합니다. 메세지 처리 함수를 변경하기 위해서 become() 을 사용해야 하고 액터 내부의 상태를 mutable ( var ) 로서 관리해야 합니다. 저는 이로 인해 액터 코드가 상당히 복잡하고 스파게티처럼 꼬여있는 것 같다는 느낌을 많이 받았고 코드를 분석하고 유지보수하는게 까다롭다고 느꼈습니다. 그러면 akka typed 은 이러한 문제들을 어떠

안녕하세요~ 오늘은 스칼라에서 비지니스 로직을 purely functional 하게 설계하는 방법에 대해서 소개해볼까 합니다. 함수형 프로그래밍, 스칼라, cats, DDD 에 대해서 알고 계시면 이해가 수월하시겠지만 모르시는 분들을 위해서 기본적인 설명도 같이 첨부해두었습니다. 다루는 내용 cats 의 RWST (ReaderWriterStateT) 를 활용해서 핵심 비지니스 로직을 purely functional 하게 작성하는 방법 그렇게 작성된 비지니스 로직을 DDD (Domain Driven Development) 설계에서 사용하는 방법 비지니스 로직에 대한 고찰 소프트웨어 설계와 개발에 있어서 가장 중요한 건 요구사항 분석이라고 생각합니다. 그리고 그러한 요구사항을 처리하기 위한 로직 (즉, 비지니스 로직) 을 잘 구현하고 테스트하는 것이 개발에 있어서 가장 우선순위라고 생각합니다. DDD (Domain Driven Development) 에서는 이러한 비지니스 로직들을 도메인 레이어에 위치시키고 핵심 도메인 엔티티와 규칙을 나타내는 코드는 세부 구현 (어떤 DB 를 사용하는지, 어떤 라이브러리를 사용하는지, 외부와 어떻게 통신하는지 등등) 에 의존하지 않도록 설계합니다. 자, 그렇다면 비지니스 로직을 도메인 레이어에 따로 분리시키고 세부 구현사항들과의 의존성을 제거하면 실질적으로 어떤 장점들이 있을까요? 인터넷에 검색해보시면 많은 이야기들을 보실 수 있는데요. 제가 경험한 장점들을 살짝 나열하자면 다음과 같습니다. 비지니스 로직과 요구사항들이 한눈에 들어오고 관리가 용이해집니다. 세부구현과의 의존성이 적으므로 테스트가 용이해집니다. 추후에 프레임워크나 기반 인프라를 변경하는 것이 용이해집니다. (보통 프레임워크나 인프라 위에서 비지니스 로직을 구현하는 것이 자연스럽다고 생각하실 수도 있지만 DDD 에서는 비지니스 로직이 가장 안쪽에 레이어에 위치하고 프레임워크나 인프라는 바깥 레이어에 위치하도록 하기때문에 이런