필요한 내용만 추려서 DDD 당장 써먹기
그런 일이 가능할까? DDD 같은 개념서를 다 읽지도 않고, 필요한 내용만 대충 훑어서 써먹는 식 말이다. 못할 이유가 뭐가 있는가? 가능하다. 책을 다 읽는다고 해도 소화한 내용 중에서 당장 응용할만한 부분만 구현에 써먹기 마련이다. 책을 다 읽으나 안 읽으나 어차피 일부만 소화해서 써먹을 수 있다면, 책을 안 읽고 써먹는 방법이
그런 일이 가능할까? DDD 같은 개념서를 다 읽지도 않고, 필요한 내용만 대충 훑어서 써먹는 식 말이다. 못할 이유가 뭐가 있는가? 가능하다. 책을 다 읽는다고 해도 소화한 내용 중에서 당장 응용할만한 부분만 구현에 써먹기 마련이다. 책을 다 읽으나 안 읽으나 어차피 일부만 소화해서 써먹을 수 있다면, 책을 안 읽고 써먹는 방법이
이 글은 갑자기 벌어진 일상의 장면에서 나 자신이 어떻게 행동하는지 스캔하듯 돌아본 글이다. 그 과정에서 내면을 관찰하고 긍정적인 방향으로 항해하려고 노력한 기록을 사후 해석해보는 시도이다. CostApproval (비용-결재) 이라는 이름은 적절한가? 최초의 나의 질문은 동료가 지은 이름을 검토하는 일이었다. 처음에는 영어 표현이 옳은지 살피려 했는데, 습관적으로 위키피디아로 나아갔다. 그런 습관적
낮에 동료가 칠판에 그린 그림과 설명하는 말을 듣고, 동료의 질문에 답을 하다가, 무려 1994년에 나온 디자인 패턴 내용을 말하게 된 사연이다. 상속 대신 위임 그가 그린 그림은 아래와 같다. 나는 그에게 물었다. Order가 Sale을 포함한다는 말은 무엇을 의미하냐? 그는 자기 인식과 프로그램으로 구현한 내용을 나름대로 명확하게 설명했다. 나는 구현에 대해
도전적인 제목이다. 예전에는 무려 어떤 컨퍼런스 자리에서 설계 담론을 정리해보겠다고 선언만 하고, 용두사미로 내용없는 발표를 한 일도 있었다. 흑역사다. 그럼에도 불구하고 또 무모한 도전을 해볼 생각이다. 난 직업 작가가 아니라 글 내용으로 욕을 좀 먹어도 괜찮다. 다만, 내가 직업으로 하는 일에서 축적한 내용이 매우 빈약하다는 사실이 무모한 도전을 하게 만든다고
이 글은 도메인 주도 설계Domain-Driven Design(이하 DDD)에서 말하는 값 객체Value Object가 무엇인지 알아보고 마이크로서비스 환경에서 값 객체를 활용하는 법을 다룬다. 값 객체란 무엇인가? 전자 상거래 사이트에서 상품을 받을 주소(배송지)를 입력하고 주문한다고 생각해 보자. 시스템에서 배송지를 임의로 수정한다면 상품은 정상적으로 배송되지 못할 것이다. 따라서 시스템은 배송지를
인터넷 끊으면 됨. 피싱이고 APT고 랜섬웨어고 뭐고 다 인터넷만 끊으면 걱정 끝. 이후엔 톰아저씨만 조심하며 된다. 진짜로(..) 피싱 등으로 직원 PC가 털린 후 고객정보 유출로 이어진 동종 업계 사례 때문에 고민인 분을 만났다. 근데 이분 본업은 DBA라고.-_- 내부에서 간단하게 위험을 모니터링할 수 있는 방법을 알려달라고 하는데, 네트워크 통신량같은 거 보는
동료 유영모가 ID로 다른 애그리게잇을 참조하라에서 애그리게잇을 본문에서 조립물로 바꾼 사연에 대한 이야기다. 두레이로 popit 글 검토를 하는 우리회사 popit 글 검토는popit 저자들이 글을 쓰는 워드프레스 시스템 상에서 벌어진다. 그런데, 사내에서 쓰는 두레이로 우리끼리 대화를 하고 싶어서 회사안에서는 채널을 만들었다. 워드프레스는 결과물 편집은 좋지만, 의견을 주고 받기는 어려우니까. 그러던 차에
필자는 지난 글 전반부에서 도메인 주도 설계Domain-Driven Design에서 말하는 구조물 중 하나인 조립물AGGREGATE[1]에 대해 이야기했다. 조립물을 구현하다 보면 다른 조립물을 참조해야 할 때가 있다. 이를 구현하는 방식은 크게 조립물의 루트 엔터티Root Entity 객체를 참조(포인터) 하는 것과 식별자로 어디서든 쓸 수 있는 값을 사용하는 방법(ID)이
(이미지 - https://aws.amazon.com/emr/features) AWS EMR 은 정말 좋은 툴입니다. (가격만 안비싸고 좀만 더 빨리 뜨면) * 버튼 눌러서 쉽게 만들 수 있고 * Spark, Presto, Flink 등 설치된 클러스터에 필요한 Job 만 던지면 되고 * Zeppelin, Jupyter 등 탐색을 위한 도구도 바로 사용할 수 있습니다. 늘 그렇듯이 해보니 된다
애초에 이글은 동료에게 시스템 맥락도[1]Context diagram를 설명하며 쓰던 글인데 독자 타겟을 바꿔 포괄적으로 시스템을 둘러싼 오해를 드러낼 목적으로 고쳤다. 시스템은 사용자를 포함하는가? 시스템 맥락을 그리는 일은 20년 가까이 해오던 일종의 틀에 박힌 일이다. 그런데, 배경 지식이나 경험 없이 처음으로 그려보려고 질문하는 동료를 만나는 순간 새삼 없던 흥미가 솟아나는
해당 코드는 Github를 확인해주세요. Spring Guide 1. Test 전략 가이드 2. Exception 전략 가이드 3. Domain 객체 가이드 4. 외부 API 가이드 5. Service 적절한 크기 가이드 Exception Guide 스프링은 예외처리를 위해 다양하고 막강한 어노테이션을 제공하고 있습니다. 일관성 있는 코드 스타일을 유지하면서 Exception을 처리하는 방법에 대해서 소개하겠습니다. 통일된 Error Response
다음은 단골 강의 주제인 secure 로그 프로세스 발생 통계. 발생한 프로세스의 종류는 6개. 사전 분석 과정에서는 분명 7개였는데, sudo 프로세스 어디갔지?-_- grok 필터에 사용된 정규표현식을 살펴봤다. login과 sshd 프로세스로만 테스트했구나. 그래도 다른 프로세스는 다 추출됐는데 왜 sudo만 빠졌을까? 검사 대상에 sudo 프로세스도 포함시켜봤다. 다른 프로세스는 이어지는 문자열과 하나의 '공백&