본문 바로가기

로버트 C. 마틴(Robert C. Martin)38

클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 7부 : 맺는 글 [맺는 글-제이슨 고먼] 1990년대로, Big Architecture(모든 것을 완벽하게 분석하고 설계한 후 구현하고 테스트하며, 이후 빅뱅 통합 과정을 거치는 아키텍처)라는 공룡이 세계를 지배하던 시기였다. 출세하려면 객체나 컴포넌트, 디자인 패턴, UML을 배워야만 했다. 설계 단계에는 '선임' 프로그래머가 시스템에 대한 상세한 청사진을 펼치고, 대다수의 '후배' 프로그래머가 따르도록 만들었다. 물론 지켜지지는 않았다. 단 한 번도. 다행히도 이후에 애자일 소프트웨어 개발이라는 혁명이 발발했고, 나와 같은 아키텍트를 이 불행으로부터 벗어나게 해 주었다. 나는 프로그래머다. 나는 프로그래밍을 좋아한다. 그리고 코드에 긍정적인 영향을 줄 수 있는 방법 중 내가 발견한 최고는 코드를 작성하는 일이다. B.. 2020. 3. 30.
클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 7부 : 부록 [7부] 부록 (일) [부록A] 아키텍처 고고학 [조합 회계 시스템] [레이저 트리밍] [알루미늄 다이캐스팅 모니터링] [4-TEL] [4-TEL 서비스 지역 컴퓨터] [C언어] [BOSS] [pCCU] [DLU/DRU] [VRS] [전자 접수원] [수리기사 파견 시스템(CDS)] [Clear Communications] [로즈] [건축사 인증 시험] [결론] 2020. 3. 29.
클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 6부 : 세부사항 (34장) [34장] 빠져 있는 장 악마는 항상 디테일(구현 세부사항)에 있는 법이며, 이점을 심사숙고하지 않는다면 마지막 고비에 걸려 넘어지기 십상일 것이다. [계층 기반 패키지] 가장 단순한 첫 번째 설계 방식은 전통적인 수평 계층형 아키텍처다. 기술적인 관점에서 해당 코드가 하는 일에 기반해 그 코드를 분할한다. ‘계층 기반 패키지’ 코드는 계층이라는 얇은 수평 조각으로 나뉘며, 각 계층은 유사한 종류의 것들을 묶는 도구로 사용된다. ‘엄격한 계층형 아키텍처’의 경우 계층은 반드시 바로 아래 계층에만 의존해야 한다. 이 아키텍처는 엄청난 복잡함을 겪지 않고도 무언가를 작동시켜 주는 아주 빠른 방법이다. 문제는, 소프트웨어가 커지고 복잡해지기 시작하면 머지 않아 큰 그릇 세 개만으로는 모든 코드를 담기엔 부족하.. 2020. 3. 28.
클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 6부 : 세부사항 (33장) [33장] 사례 연구: 비디오 판매 [제품] 시스템의 초기 아키텍처를 결정하는 첫 단계는 액터와 유스케이스를 식별하는 일이다. [유스케이스 분석] 단일 책임 원칙에 따르면 이들 네 액터가 시스템이 변경되어야 할 네 가지 주요 근원이 된다. 신규 기능을 추가하거나 기존 기능을 변경해야 한다면, 그 이유는 반드시 이들 액터 중 하나에게 해당 기능을 제공하기 위해서다. 따라서 우리는 시스템을 분할하여, 특정 액터를 위한 변경이 나머지 액터에게는 전혀 영향을 미치지 않게 만들고자 한다. 네 액터 : 제작자, 관리자, 구매자, 시청자 추상 유스케이스는 범용적인 정책을 담고 있으며, 다른 유스케이스에서 이를 더 구체화한다. 한편 이 추상화를 꼭 생성해야만 했던 건 아니다. [컴포넌트 아키텍처] 이제 액터와 유스케이.. 2020. 3. 27.
클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 6부 : 세부사항 (32장) [32장] 프레임워크는 세부사항이다 프레임워크는 아키텍처가 될 수 없다. [프레임워크 제작자] 프레임워크 제작자는 자신이 해결해야 할 고유한 문제나 자신의 동료와 친구들의 문제를 알고 있다. 그리고 그러한 문제들을 해결하기 위해 프레임워크를 만든다. 당신의 문제를 해결하기 위해서가 아니다. [혼인 관계의 비대칭성] 당신과 프레임워크 제작자 사이의 관계는 놀라울 정도로 비대칭적이다. 당신은 프레임워크를 위해 대단히 큰 헌신을 해야 하지만, 프레임워크 제작자는 당신을 위해 아무런 헌신도 하지 않는다. 문서에서 프레임워크 제작자와 그 프레임워크의 다른 사용자는 우리가 만들 소프트웨어와 프레임워크를 어떻게 통합할 수 있을지 조언한다. 대개의 경우 이들ㅇ느 프레임워크를 중심에 두고 우리의 아키텍처는 그 바깥을 감.. 2020. 3. 26.
클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 6부 : 세부사항 (31장) [31장] 웹은 세부사항이다 사실 웹이 바꾼 것은 아무것도 없었다. 아니 적어도 웹은 그렇게 해서는 안 됐었다. 1960년대 이래로 우리 업계는 일련의 반복되는 진동을 겪어왔고, 현재 웹은 그저 이러한 진동의 맨 끝에 있을 뿐이다. 이 진동은 모든 연산 능력을 중앙 서버에 두는 방식과 모든 연산 능력을 단말에 두는 방식 사이에서 끊임없이 움직여 왔다. [끝없이 반복하는 추] 그리고 그 이야기는 계속된다. 앞으로도 우리는 연산 능력을 어디에 둘지 알 수 없을 것이다. 연산 능력을 중앙에 집중하는 방식과 분산하는 방식 사이에서 우리는 끊임없이 움직인다. 아키텍트로서 우리는 멀리 내다봐야 한다. 이 진동은 그저 핵심 업무 규칙의 중심에서 밀어내고 싶은 단기적인 문제일 뿐이다. 업무 규칙은 UI로부터 분리해야만.. 2020. 3. 25.