삶은달걀노른자

■ 27장 '크고 작은 모든' 서비스들 Services: Great and Small ​ 서비스는 시스템의 확장성과 개발 가능성 측면에서 유용하지만, 아키텍처적으로는 크게 중요하지 않다. 아키텍처는 경계를 넘나드는 의존성에 의해 정의되는데, 서비스는 구성요소가 통신하는 함수 호출에 지나지 않는다. ​ 아키텍처의 경계는 서비스 사이에 있지 않고 서비스를 관통하며 서비스를 컴포넌트 단위로 분할한다. 아키텍처 경계를 정의하는 것은 서비스 내에 위치한 컴포넌트다. ​ 책에서 말하는 횡단 관심사는 여러 서비스를 횡으로 나열했을 때(1111 처럼 옆으로) 이 서비스들을 횡으로 관통(---> 로)할 수밖에 없는 아키텍처 경계나 나올 수 있으며, 이를 처리하려면 서비스 내부도 의존성 규칙을 준수하는 컴포넌트 아키텍처로..

■ 26장 메인 컴포넌트 The Main Component ​ 메인 컴포넌트는 궁극적인 세부사항으로, 가장 낮은 수준의 정책이다. 운영체제만이 메인에 의존한다. ​ 메인은 초기 조건과 설정을 구성하고 외부자원을 모두 수집한 후, 제어권을 어플리케이션의 고수준 정채으로 넘기는 플러그인이라고 생각하면 된다. 아키텍처 경계 바깥에 위치한다고 보면 설정 관련 문제를 쉽게 해결할 수 있다. ​ ​ ​

ITIL 4의 시험 체계는 다음과 같은 구조로 되어 있다. 1. ITIL Foundaion 가장 하단의 ITIL Foundation 시험이 있다. 전체 시험 체계에서 가장 기본이 되는 것으로 상위 인증을 위해서는 필수사항이다. 물론 ITIL 4 이전 버전의 Foundation 시험으로도 이 조건을 충족할 수 있다. Foundation 인증 취득 후에는 MP 또는 SL 이라는 두 가지 길이 있다. 2. ITIL MP (Managing Professional) MP는 ITIL의 설계 및 구현, 운영을 담당하는 사용자를 위한 것이다. 디지털 기술 영역에서 일하는 순수 서비스 관리 전문가에게 필요한 인증이다. 시험은 심층적인 서비스 관리 지식과 프로젝트, 프랙티스, 팀 및 워크플로우에 대한 지식을 테스트한다. ..

■ 25장 계층과 경계 Layers and Boundaries ​ 아키텍처 경계는 어디에나 존재한다. 아키텍트는 이 경계가 무엇이고 언제 필요하며 구현 가능여부(비용 대비)를 신중하게 결정해야 한다. 프로젝트 초반에는 알기 어렵지만 시스템이 발전함에 따라 주의를 기울여야 한다. (아키텍처 경계에 대한 글은 17장에서 볼 수 있다) ​ 아키텍처 경계를 찾아가는 예는 아래 그림의 흐름에서 볼 수 있다. (게임 어플리케이션의 예) ​ 1. 언어 및 데이터 저장소에 무관한 게임 규칙 적용 ​ 2. 텍스트 메커니즘 확장 및 추상 컴포넌트 추가 ​ 3. 네트워크 컴포넌트를 추가하여 단순화한 다이어그램 ​ 4. 게임 정책을 상위 수준과 하위 수준으로 분리 ​ 5. 마이크로서비스 API 추가 : MoveManageme..

직장생활을 하면서 많이 사용하는 용어입니다. 인터넷에 이미 많이 올라와 있어 일부는 다른 분들의 글을 참고했고 대부분은 저의 경험을 토대로 작성하였습니다. 혹시 잘못 해석된 용어가 있다면 알려 주시면 감사하겠습니다. ​ 제가 IT 기업에 다니므로 IT 기업의 문화적 특성이 반영되었을 수 있습니다. ​ ​ • 맨먼스 M/M, Man/Month 한 사람이 한 달에 할 수 있는 일의 양 예) 이 일은 0.5 M/M 정도 되겠는데요? ​ • 티오 T/O 조직의 남은 자리 예) 우리 팀은 더이상 티오가 없어서 뽑을 수가 없대 ​ • 알앤알 R&R, Role & Responsiblity 역할, 책임이 있는 업무 예) 알앤알을 명확히 해야죠. 그건 저희 쪽 일이 아닌데요 ​ • 스콥 scope 업무의 범위 예) 스콥..

DevOps와 같이 Ops의 종류가 여러가지 있습니다. Ops는 운영, 즉 Operation의 약자이며, DevOps가 개발과 운영의 통합인 것처럼, Ops가 붙은 다른 영역 역시 해당 전문분야가 운영과 통합된 개념입니다. 그러나 사실상 모두 DevOps의 하위 개념들이라 볼 수 있습니다. ​ 각각을 깊이 이해하고 실제 적용하기 위해서는 많은 지식과 노력이 필요하지만, 우선 이런 용어도 있구나 하는 차원에서 간단하게 정리해 보았습니다. ​ ​ ● MLOps ​ Machine Learning + Ops로서 운영환경에서 머신러닝 모델을 효율적으로 배포하고 관리하기 위한 방법입니다. 머신러닝 모델을 운영에 전환하는 프로세스를 간소화하고, 이후 유지관리 단계의 모니터링에 포커싱합니다. MLOps는 머신러닝으로 ..

■ 24장 부분적 경계 Partial Boundaries ​ 완벽한 아키텍처 경계를 만드는 것은 많은 비용과 노력이 드는 일이므로 부분적인 경계를 생각해 볼 수도 있다. 독립적인 컴포넌트를 만들되 그냥 하나의 컴포넌트 안에 그대로 모아 놓는 것이다. 물론 부분적 경계를 만들려면 완벽한 경계를 만들 때만큼의 코드량과 사전 설계가 필요하지만 다수의 컴포넌트 관리에 대한 부담은 없다. ​ 부분적 경계를 구현하는 방법은 ​ 1. 컴포넌트를 분리해서 설계하되 실제로는 하나가 되도록 만들기 (다운로드 시 한 개만 다운로드) 2. Strategy 패턴을 사용하기 (패턴을 잘 몰라서 이 부분은 자세하게 모르겠다) 3. Facade 패턴을 사용하기 (상동) ​ ​

■ 23장 프레젠터와 험블 객체 Presenters and Humble Objects ​ 기본적인 본질은 남기고 테스트하기 어려운 행위만 옮겨놓은 것을 험블 humble 객체라고 한다. GUI 영역을 프레젠터와 뷰로 분리할 때 뷰에 해당하는 것이 험블이다. ​ ** Humble의 사전적 의미는 '겸손한', '변변찮은' 등이 있는데, 여기서는 '변변찮은' 혹은 '중요하지 않은'의 의미로 해석하면 될 것 같다. 'humble' : 네이버 사전 검색결과 33종 언어사전과 방대한 지식백과를 제공 dict.naver.com 프레젠터 Presenter 는 데이터를 받아 화면에 표현할 수 있는 포맷으로 만드는 역할을 한다. 가령 Date 객체를 전달받아 적절한 문자열로 만들고 이를 View model 이라고 부르는 ..

■ 22장 클린 아키텍처 Clean Architecture ​ 다양한 시스템 아키텍처가 있지만 이들의 공통된 목표는 ‘관심사의 분리’이다. 최소한 하나의 업무규칙 계층과 인터페이스 및 그밖의 다른 계층으로 분리해야 한다. ​ 또한 다음의 특징을 지닌다. ​ 프레임워크 독립성 : 업무규칙은 프레임워크에 의존하지 않으며 단지 그것을 도구로 사용할 수 있어야 한다. 테스트 용이성 : 업무규칙은 UI나 데이터베이스, 웹 서버 등의 외부 요소가 없이도 테스트 될 수 있어야 한다. UI 독립성 : 업무규칙을 변경하지 않고 UI를 바꿀 수 있어야 한다. 데이터베이스 독립성 : 업무규칙을 변경하지 않고 DBMS를 바꿀 수 있어야 한다. 모든 외부 에이전시에 대한 독립성 : 업무규칙은 외부 세계의 인터페이스에 대해 전혀..

■ 21장 소리치는 아키텍처 Screaming Architecture ​ 집의 설계도를 보고 이건 집이야 라고 소리칠 수 있고, 도서관의 설계도를 보고 이건 도서관이야 라고 소리칠 수 있듯이 소프트웨어의 아키텍처 역시 이건 헬스케어 시스템이야 혹은 이건 재고관리 시스템 이야 하고 소리칠 수 있어야 한다. ​ 이렇게 하기 위해서는 소프트웨어 아키텍처는 유스케이스가 중심이 되어야 한다. 프레임워크, 데이터베이스, 웹 서버, 기타 개발환경이나 도구는 변두리의 지엽적인 문제로 이들은 최대한 뒤로 결정을 미룰 수 있어야 한다. ​ 웹은 전달 메커니즘(입출력 장치)일 뿐 아키텍처 자체는 아니다. 따라서 아키텍처는 시스템을 웹으로 할지, 앱으로 할지, 또는 C/S로 할지에 대한 결정을 최대한 뒤로 미뤄야 한다. 프레..