Return to Video

Robert C. Martin - Clean Architecture and Design

  • 4:47 - 4:50
    뒤에 잘 들리나요?
  • 4:51 - 4:56
    저 뒤에도 잘 들리나요? 오케이 좋습니다.
  • 4:57 - 5:03
    Um what is an electron?
  • 5:03 - 5:08
    So part of atom, everybody knows that, I think
  • 5:08 - 5:18
    It's um.. (Screams from other room) yeah I think so, . I think that's royal ???
  • 5:18 - 5:23
    Um electron is part of atom
  • 5:23 - 5:32
    it's carries a unit of electronic charge, negative charge, as oppose to a proton which carries a positive charge
  • 5:32 - 5:42
    It apparently has ??? not very much, thousands of electron... very very small amount of mass
  • 5:43 - 5:56
    And we think of it as a particle, although that misleading um.. electron actually behaves much more like a wave than like a particle
  • 5:56 - 5:59
    why do we think of it as particle?
  • 5:59 - 6:09
    and the reason we do that is that when electron interacts a location like a particle would
  • 6:09 - 6:16
    when electron is moving through the space it does not moves the way a particle would
  • 6:16 - 6:21
    moves as a wave and the wave has no location
  • 6:21 - 6:25
    you look at an ocean wave, and ocean wave can be huge
  • 6:26 - 6:34
    it has no distinct location it has well defined energy but no distinct location
  • 6:34 - 6:35
    this is how an electron moves
  • 6:36 - 6:39
    electrons obey a principle and it's a mistruster principle
  • 6:42 - 6:46
    It's called the poly exclusion principle
  • 6:46 - 6:53
    two electrons bound into the same system will not be in the same state
  • 6:53 - 6:57
    for whatever reason they cannot be in the same state
  • 6:57 - 7:01
    so if there are two electrons in an atom
  • 7:01 - 7:04
    those two electrons must be different somehow
  • 7:04 - 7:07
    now they might different in the direction of their spin
  • 7:07 - 7:11
    an electron can spin to the left or spin to the right
  • 7:11 - 7:18
    two electrons that have exactly same energy could fit together spinning one left and one right
  • 7:18 - 7:21
  • 7:21 - 7:27
  • 7:27 - 7:30
  • 7:30 - 7:35
  • 7:35 - 7:38
  • 7:38 - 7:48
  • 7:48 - 7:58
  • 7:58 - 8:09
  • 8:09 - 8:11
  • 8:11 - 8:15
  • 8:17 - 8:18
  • 8:20 - 8:25
  • 8:25 - 8:27
  • 8:27 - 8:34
  • 8:34 - 8:40
  • 8:40 - 8:46
  • 8:46 - 8:51
  • 8:51 - 8:55
  • 8:55 - 9:03
  • 9:03 - 9:11
  • 9:11 - 9:20
  • 9:20 - 9:25
  • 9:25 - 9:31
  • 9:31 - 9:35
  • 9:35 - 9:46
  • 9:46 - 9:54
  • 9:54 - 9:58
  • 9:58 - 10:02
  • 10:02 - 10:08
  • 10:08 - 10:11
  • 10:11 - 10:23
  • 10:23 - 10:34
  • 10:34 - 10:37
  • 10:37 - 10:43
  • 10:43 - 10:52
  • 10:52 - 11:03
  • 11:03 - 11:06
  • 11:06 - 11:09
    물론 오늘의 발표 주제는 이게 아니지요.
  • 11:10 - 11:20
    오늘 이야기할 주제는 "아키텍처, 잃어 버린 시간" 입니다.
  • 11:20 - 11:24
    이 것은 클린 코드와 클린 디자인의 다음 단계에 대한 이야기입니다.
  • 11:29 - 11:32
    클린 시스템 스트럭쳐에 대한 이야기 입니다.
  • 11:32 - 11:38
    이 그림은 내가 10년 전에 작성했던 어플리케이션의 디렉터리 구조입니다.
  • 11:38 - 11:47
  • 11:47 - 11:52
    당시에 Rails를 배우고 있었지요.
    여기 Ruby 프로그래머가 있나요? Ruby on Rails 프로그래머?
  • 11:53 - 11:57
    저쪽에 손 흔드는 사람이 한 명 있네요. 오케이.
  • 11:57 - 12:03
    당시에 Rails를 배우면서 이 어플리케이션을 작성했는데 책의 내용을 따라 했습니다.
  • 12:03 - 12:10
  • 12:10 - 12:14
    책에서 이야기하는데로 그대로 작성했더니 이런 형태의 결과가 나왔습니다.
  • 12:14 - 12:20
    만족스럽게 마무리했고 그뒤로 오랫동안 안 봤습니다.
  • 12:20 - 12:27
    그리고 한 3년 전에 내 아들한테 어플리케이션을 하나 작성해달라고 했습니다.
  • 12:27 - 12:34
    그런데 작성된 어플리케이션을 보니 디렉터리 구조가 똑 같았어요.
  • 12:35 - 12:41
    이 둘은 전혀 다른 어플리케이션이고 아무런 연관도 없습니다.
  • 12:41 - 12:53
    그런데 디렉터리 구조는 똑 같아요. 이걸 보면서 왜 두 어플리케이션의 최상위 구조가 똑 같은지에 대해서 고민했습니다.
  • 12:53 - 12:57
    이 둘은 전혀 다른 어플리케이션이거든요.
  • 12:57 - 13:02
    두 어플리케이션의 디렉터리 구조가 동일한 이유는 둘다 Rails 어플리케이션이기 때문이었습니다.
  • 13:02 - 13:08
    그러자 이게 왜 중요한지가 궁금해졌습니다.
  • 13:08 - 13:20
    Rails 같은 프레임워크가 얼마나 중요하길래 어플리케이션의 최상위 디렉터로 구조를 결정지어버리는 걸 까요?
  • 13:21 - 13:25
    내가 생각한 이유는 바로 다음과 같습니다.
  • 13:25 - 13:34
    웹은 전달을 위한 장치입니다. 웹은 I/O 채널이에요.
  • 13:35 - 13:38
    웹 자체는 아키텍처적으로 중요하지 않습니다.
  • 13:38 - 13:52
    흔히 웹 어플리케이션을 작성한다고 생각하는데 그렇지 않습니다. 우리는 컨텐츠를 전달하는 어플리케이션을 작성하고 있는 것 입니다.
  • 13:52 - 13:57
    그러면 왜 I/O 채널이 그렇게 중요할까요?
  • 13:57 - 14:07
    혹시 웹이 번성하기 시작한 시기를 기억하나요? 1980년대? 1990년대?
  • 14:07 - 14:13
    얼마나 큰 변화였는지 기억하나요? 얼마나 모든 것이 근본적으로 변했는지 기억하나요?
  • 14:13 - 14:20
    그렇게 큰 변화는 없었습니다. 왜냐하면 실제로 그다지 새로운 것이 아니었기 때문이지요.
  • 14:20 - 14:27
    우리는 단지 입력 소스로 부터 입력을 받고, 처리하고, 출력 소스로 내보내기만 했습니다.
  • 14:27 - 14:28
    웹은 그냥 그런거에요.
  • 14:28 - 14:31
    그런데 왜 왭이 모든 것들을 결정해버릴까요?
  • 14:31 - 14:39
    그래서 나는 건축에 대해서 생각해봤습니다. 건축 도면을 봤어요.
  • 14:39 - 14:50
    저 건축 도면을 보세요. 첫 눈에 도서관 도면이라고 생각이 안들어도 깨닫는데까지 얼마 걸리지 않을 겁니다.
  • 14:50 - 14:52
    도서관이라는게 너무 명백하거든요.
  • 14:52 - 14:56
    책장들이 많이 있고 책상도 많습니다.
  • 14:56 - 15:06
    책상위엥 컴퓨터도 보이고요 책을 대출하고 반납하는 곳도 보여요.
  • 15:06 - 15:11
    저 도면을 보고 도서관이라는 것을 알아채는데에 오랜 시간이 걸리지 않을 겁니다.
  • 15:11 - 15:16
    다른 것도 봐볼까요? 저건 교회에요. 누가 봐도 교회지요.
  • 15:16 - 15:22
    어쩌면 극장이라고 생각할 수 도 있겠지요. 극장이랑 교회는 공통 부분이 있으니까요.
  • 15:22 - 15:30
    하지만 이건 분명히 교회입니다. 제단, 바깥의 교실,
  • 15:30 - 15:32
    분명히 교회지요.
  • 15:32 - 15:42
    이 건물의 아키텍처는 어떻게 지어지는지 이야기하지 않습니다.
  • 15:42 - 15:47
    이 건물의 아키텍처는 그 의도 이야기하고 있지요. 아키텍처라는 것은 의도에 대한 것 입니다.
  • 15:47 - 15:56
    하지만 저 Rails 어플리케이션들의 최상위 구조는 그 의도에 대해서 이야기하지 않고 있지요.
  • 16:02 - 16:02
    저 어플레케이션들은 스스로 Rails 어플리케이션이라는 것을 이야기하고 있습니다. 무언가 잘못되었어요.
  • 16:02 - 16:05
    그리고 이런 생각이 들었습니다.
  • 16:05 - 16:16
    이건 이미 알려진 문제인가? 이미 해결되었던 문제인가? 이 문제는 1992년에 Iva jacobson이 저술한 책에서 거론되고 해결되었었습니다.
  • 16:16 - 16:21
    이 책을 가진 사람이 있나요? 읽어 본 사람? 여기 한 사람있네요 또 없나요?
  • 16:21 - 16:23
    Object-Oriented Software Engineering. 아주 훌륭한 책이에요.
  • 16:24 - 16:30
    1992년에 출반된 책이지만 상관없어요. 책에 담긴 원칙들은 여전히 유효합니다.
  • 16:30 - 16:37
    부제를 보세요. 부제는 'A Usecase driven approach' 입니다.
  • 16:37 - 16:45
    유즈케이스 기억하는 사람 있나요? 1990년대에는 아주 아주 유명했었습니다.
  • 16:45 - 16:54
    실제론 너무 유명해서 수많은 컨설턴트들에 의해 본래의 의미가 변질되었었지요.
  • 16:54 - 17:07
    수많은 컨설턴트들이 자신의 유즈케이스 양식을 인터넷에 앞다퉈서 내놓았었지요.
  • 17:07 - 17:13
    그러더니 양식 자체가 매우 중요하게 여겨져 버렸어요. 우리는 그 표준 양식의 빈칸을 채우도록 강요받았지요.
  • 17:13 - 17:29
    유즈케이스의 이름, 입력값, 사전조건, 사후조건, 주액터, 부액터 등을 채워야했습니다.
  • 17:29 - 17:38
    우리는 모든 빈칸을 채워야만했고 결국 유즈케이스의 가장 중요한 점은 그 기능이 아니라 양식이 되버렸습니다.
  • 17:38 - 17:52
    그 시기의 절정 즈음에 에자일 운동이 시작되었습니다. 우리는 유즈케이스에 대한 이야기는 멈추고 유저 스토리에 대해 이야기했습니다. 유즈케이스에 대해서는 아무도 이야기하지 않게되었지요.
  • 17:52 - 17:58
    그래서 나는 이 책을 다시 읽어봤어요.
  • 17:58 - 18:02
    Jacobson이 쓴것들을 다시 기억해냈습니다.
  • 18:02 - 18:11
    여기 유즈케이스가 있습니다. 전형적인 Jacobson 스타일의 유즈케이스에요.
  • 18:11 - 18:24
    매우 작은 양식이에요. '주문 생성'이라는 이름이 있네요. 주문 처리 시스템의 유즈케이스라고 생각해보세요.
  • 18:24 - 18:33
    입력 값으로 고객 아이디, 고객 연락처, 수신처 등이 보이네요.
  • 18:33 - 18:38
    여기에는 세부적인 내용은 없어요. 고객 아이디가 어떤 것인지 기술하지 않습니다.
  • 18:38 - 18:40
    숫자이건 문자열이건 상관없어요.
  • 18:40 - 18:48
    고객 연락처가 어떤 것인지 기술하지 않습니다. 아마도 이름 날자 주소등등 이겠지요.
  • 18:48 - 18:52
    하지만 세부사항들연 여기에 명시되어있지 않습니다.
  • 18:52 - 19:05
    여기 메인 흐름이 있네요. 메인 흐름은 유즈케이스를 만족시키기 위해 컴퓨터가 실행하는 단계들이에요.
  • 19:05 - 19:11
    첫 번째로 주문 담당자는 '주문 생성'을 요청합니다.
  • 19:11 - 19:19
    그리고 시스템이 데이터를 검증합니다. 어떻게 검증한다는 이야기는 안했지요? 어떻게든 검증을 하는지는 중요하지 않습니다. 그냥 검증을 한다는게 중요합니다.
  • 19:19 - 19:28
    세번째로 시스템이 주문을 생성하고 ID를 결정합니다. 아마도 어떤 데이터베이스 작업이겠지만 이야기는 안하겠습니다.
  • 19:28 - 19:35
    그리고 시스템은 담당자에게 ID를 전달합니다. 아마도 웹 페이지를 통해서겠지만 이야기는 안하겠습니다.
  • 19:35 - 19:44
    실제로 이 유즈케이스는 웹에 대해 아무런 이야기도 하지 않습니다. 이 유즈케이스는 어떤 I/O 채널을 통해서도 구현이 가능하겠지요.
  • 19:44 - 19:53
    이 유즈케이스는 콘솔 앱, 데스크탑 앱, SOA 앱, 아이폰 앱에서도 구현이 가능합니다.
  • 19:53 - 20:00
    유즈케이스는 I/O 채널을 모르기 때문에 가능한 것 입니다.
  • 20:00 - 20:09
    Jacobson은 유즈케이스를 오브젝트로 바꿀 수 있다고 했습니다.
  • 20:09 - 20:19
    Jacobson은 저것을 Control Object라고 불렀지만 MVC의 Controller와 헷갈릴 수 있으므로 Interactors라고 이름을 바꿨습니다.
  • 20:19 - 20:26
    어쩌면 유즈케이스라는 이름이 더 좋겠지만 그렇게 하지는 않았습니다. Interactors로 부르겠습니다.
  • 20:26 - 20:38
    Interactor 오브젝트는 유즈케이스를 구현합니다. 유즈케이스의 입력값을 입력 받아서 유즈케이스의 출력값을 출력합니다.
  • 20:38 - 20:45
    그리고 유즈케이스의 처리 흐름을 구현합니다.
  • 20:45 - 20:54
    밑에 설명을 보면 어플리케이션 별 비지니스 규칙들을 가진다고 되어있지요?
  • 20:54 - 20:57
    거기에는 두 종류의 비지니스 규칙이 있습니다.
  • 20:57 - 21:07
    먼저 글로벌할 비지니스 규칙이 있습니다. 모든 어플리케이션에 적용이 가능하지요.
  • 21:07 - 21:12
    그리고 개발중인 어플리케이션에만 해당하는 비지니스 규칙들이 있습니다.
  • 21:12 - 21:22
    예를 들어서 주문 입력 어플리케이션과 주문 처리 어플리케이션이 있다고 생각해봅시다.
  • 21:22 - 21:30
    둘 다 '주문'이라는 오브젝트가 있을겁니다. 그리고 그 주문 오브젝트들은 같은 비지니스 규칙을 가지고 있겠지요.
  • 21:30 - 21:40
    하지만 둘 중 하나의 어플리케이션만 주문 추가라는 유즈케이스를 가지고 있을 겁니다.
  • 21:40 - 21:48
    유즈케이스는 어플리케이션에 따라 다릅니다. 유즈케이스는 특정 어플리케이션에 종속되지요.
  • 21:48 - 21:57
    비지니스 규칙은 어플리케이션에 따라 다르지 않습니다. Entity 오브젝트에 종속됩니다. 비지니스 오브젝트라고 불려지기도 합니다.
  • 21:57 - 22:01
    나는 비지니스 오브젝트라는 말은 좋아하지는 않습니다. Jacobson 도 Entiry 오브젝트라고 불렀지요.
  • 22:01 - 22:10
    어플리케이션 비종속적인 비지니스 규칙들을 Entity 오브젝트에 넣고 Interactor가 Entity 오브젝트들을 관장합니다.
  • 22:10 - 22:17
    그런 후에 유즈케이스의 입력값과 출력값을 다른 유즈케이스에 전달하는 방법을 정합니다.
  • 22:18 - 22:30
    이 경우에는 인터페이스를 사용합니다. 그림에 객체지향 방식의 인터페이스로 표현을 했는데요. Interactor는 인터페이스 하나를 사용하고 있고요 다른 하나의 인터페이스는 구현을 하고 있습니다.
  • 22:30 - 22:39
    Interactor가 구현하고 있는 것은 입력 인터페이스이고요 Interactor가 사용하고 있는 것은 출력 인퍼테이스입니다.
  • 22:39 - 22:42
    두 인터페이스와 Interactor 사이의 화살표가 같은 방향이지요? 이 것이 중요한 것 입니다!!!!!
  • 22:42 - 22:42
    이게 왜 중요한지는 조금 뒤에 이야기하겠습니다.
  • 22:45 - 22:54
    Jacobson은 이 세가지 오브젝트들을 자신의 아키텍처로 이야기했습니다.
  • 22:54 - 22:56
    자 그럼 이것들이 어떻게 작용하는지 봅시다.
  • 22:56 - 23:03
    일반적인 어플리케이션이 있습니다. 저기 있는 작은 사람이 유저입니다.
  • 23:03 - 23:11
    실제 사람이고요 이 사람이 전달 매커니즘을 통해서 시스템과 상호작용합니다.
  • 23:11 - 23:13
    전달 매커니즘은 웹일 수도 아닐수도 있겠지요. 아무런 상관 없습니다.
  • 23:13 - 23:26
    저 유저는 버튼이나 키보드를 사용해서 시스템이 데이터를 받아들이도록 합니다.
  • 23:26 - 23:32
    웹이건 다른 것이건 어떤 전달 메커니즘을 통하는지는 중요하지 않습니다.
  • 23:32 - 23:37
    시스템에 전달된 데이터는 Request Model이라는 것으로 변형됩니다.
  • 23:37 - 23:51
    Request Model은 순수한 데이터 구조입니다. POJO나 POCO와 같은 순수 데이터 구조 입니다. 데이터가 어디에서 왔는지 모르고 웹과 아무런 연관도 없습니다.
  • 23:51 - 23:53
  • 23:53 - 23:57
    메소드도 없는 단순한 데이터 구조입니다.
  • 23:57 - 24:02
    Public 데이터만 있는 구조로서 모든 입력값을 저장하게됩니다.
  • 24:02 - 24:11
    Request Model은 Interactor가 구현한 입력 인터페이스로 전달됩니다.
  • 24:11 - 24:27
    Interactor는 Reqeust Model을 받은 후에 데이터를 읽어 해석하고 작은 여러 커맨드들로 변환하여 Entity들에 보냅니다.
  • 24:27 - 24:33
    모든 비지니스 오브젝트들은 Entity로 호출되는 메소드들을 컨트롤합니다.
  • 24:34 - 24:42
    작업이 끝난 후에는 반대 방향으로 흘러갑니다. Interactor는 Entity들을 조회하여 변경사항을 확인합니다.
  • 24:42 - 24:48
    그 결과로 Result Model이라는 데이터 구조를 만들게됩니다.
  • 24:48 - 25:01
    Result Model은 또 다른 순수한 데이터 구조입니다. 단순한 POJO나 POCO이지요.
  • 25:01 - 25:11
    Result Model은 출력 인터페이스를 통해서 전달 매커니즘으로 전해집니다. 어떤 방법이 사용되건 출력 인터페이스를 통해서 유저에게 전달이 됩니다.
  • 25:11 - 25:15
    저건 다른 모든 어플리케이션들의 흐름이지요.
  • 25:15 - 25:20
    그럼 Interactor를 테스트할 수 있을까요?
  • 25:20 - 25:25
    매우 쉽겠지요?
  • 25:25 - 25:30
    입력 데이터 자료를 생성해서 Interactor를 호출하고 출력 데이터를 보면됩니다.
  • 25:30 - 25:33
    이걸 위해 웹 서버가 필요할까요?
  • 25:33 - 25:41
    아닙니다. Interactor는 단순히 POJO나 POCO만을 사용하기 때문이지요.
  • 25:41 - 25:45
    이걸 위해 데이터베이스가 필요할까요? 어쩌면 필요할 수도 있겠지요 하지만 이 문제는 조금 있다가 이야기하겠습니다.
  • 25:45 - 25:51
    전달 메커니즘이 없어도 테스트가 가능합니다.
  • 25:51 - 25:57
    전달 매커니즘이 웹 인가요? 상관 없습니다. Interactor를 테스트하는데에 웹 서버는 실행할 필요가 없어요.
  • 25:57 - 25:58
    테스트에는 웹 페이지도 역시 필요 없습니다.
  • 25:58 - 26:06
    시스템을 테스트 하는데에 처음 입력단 부터 마지막 출력단까지 확인안해도 테스트가 가능합니다.
  • 26:06 - 26:14
    MVC는 어떨까요?
  • 26:14 - 26:18
    MVC는 우리 모두가 해야만 하는 것 아닐까요?
  • 26:18 - 26:28
    MVC는 무어의 약자이지요? Model View Controller 입니다. 그럼 누가 발명했나요?
  • 26:28 - 26:35
    저 사람입니다. 이제 나는 저사람의 이름을 잘못 발음할 겁니다. 당신들이 나모다 더 제대로 발음하겠지요.
  • 26:35 - 26:41
    어쨌든 이야기하자면 트릭뷔 륀스카욱. 당신들이 나보다 더 정확히 발음하겠지요.
    (트릭뷔 륀스타욱은 청중들과 마찬가지로 노르웨이 사람임.)
  • 26:41 - 26:47
    나는 저 사람을 만나봤습니다. 저 사람이 1970년대에 MVC를 발명한 사람입니다.
  • 26:47 - 26:50
    나흔 저 사람을 한 번 만났는데요, 2년전 여기 이 컨퍼런스에서 였습니다.
  • 26:50 - 26:58
    나는 강연자 라운지에서 전원 콘센트를 찾고 있었습니다. 그때 저 나이든 분이 내게와서 콘센트를 건네 줬습니다.
  • 26:58 - 27:01
    고개를 올려 보니 "트릭뷔 린스카욱!"
  • 27:01 - 27:06
    멀티냅을 주고 받는 사이에 서로 손가락이 스쳤어요!
  • 27:06 - 27:13
    나는 한동안 손을 안씼었답니다. 트뤽뷔 린스카욱.
  • 27:13 - 27:19
    몇 몇 사람이 나한테 와서 사진을 같이 찍었는데요, 나도 역시 비슷한 부류입니다.
  • 27:19 - 27:28
    70년대 말에서 80년대 초에 트뤽비 린스카욱은 Model View Controller라고 부르는 이 구조를 제시했습니다.
  • 27:28 - 27:30
    그는 스몰토크 플랫폼에서 이걸 만들었지요.
  • 27:30 - 27:42
    기본 개념은 매우 간단합니다. 비지니스 규칙을 담고있는 모델 오브젝트는 자신이 어떻게 유저에게 보여질지 전혀 모릅니다.
  • 27:42 - 27:48
    단지 순수한 비지니스 규칙입니다.
    저기 아래에 있는 컨트롤러는 입력값들을 처리합니다.
  • 27:48 - 27:59
    컨트롤러는 입력 기기들을 쳐다 봅니다. 어떤 입력 기기인지는 중요하지 않습니다. 사용자의 행동들을 Model에 대한 커맨드들로 만듭니다.
  • 27:59 - 28:01
    그리고 View가 있지요.
  • 28:01 - 28:07
    View에는 쌍선으로 그려진 화살표가 있는데요. 옵저버 관계를 의미합니다.
  • 28:07 - 28:15
    View는 Model에 등록을 해놓습니다. 그리고 Model이 변경될 때 마다 View가 화면을 업데이트하도록 불리워집니다.
  • 28:15 - 28:24
    View는 Model의 컨텐츠를 표시하거나 전달하는 역할을 담당합니다.
  • 28:24 - 28:36
    이는 GUI에 아주 효율적입니다. 그리고 콘솔, SOA 등등에도 효율적으로 적용이 가능합니다.
  • 28:36 - 28:40
    입력을 컨트롤하는 것이 있고 (Controller)
    프로세스를 컨트롤하는 것이 있고 (Model)
    출력을 컨트롤하는 것이 있습니다. (View)
  • 28:40 - 28:50
    아마도 이름을 지어진 디자인 패턴인 MVC는 아주 작은 것에 사용하기 위한 것 이었습니다.
  • 28:50 - 29:01
    MVC는 버튼에 쓰일 수 있지요. MVC는 체크박스에도 쓰일 수 있습니다. 그리고 MVC는 텍스트 필드에도 쓰일 수 있습니다.
  • 29:01 - 29:04
    스크린에는 MVC가 쓰이지 않습니다.
  • 29:04 - 29:15
    아주 옛날부터 MVC는 비틀어지고 변형되어 왔습니다. 소프트웨어 분야에서 흔히 일어나는 일이지요.
  • 29:15 - 29:24
    어떤게 정말 좋은 것이라고 이야기되면 다른 모든 사람들이 모방을 합니다. 그리곤 완전히 다른 것에 같은 이름을 붙이고는 좋은 것이라고 주장합니다.
  • 29:24 - 29:29
    객체지향도 같은 현상이 생겼고, 구조, 오브젝트 에자일 등도 마찬가지였습니다.
  • 29:29 - 29:38
    어떤 이름이 무언가 좋은 것을 가리키고 있다면 다른 사람들이 그 이름을 자신의 것에 붙이고 자신의 것도 좋은 것이라고 합니다.
  • 29:38 - 29:43
    그건 MVC에도 발생했습니다. 요즘 MVC 프레임워크들이 많이 있지요.
  • 29:43 - 29:51
    그 MVC 프레임워크들은 원래 MVC와는 전혀 다릅니다. 트릭뷔 린스카욱의 MVC의 개념과 다릅니다.
  • 29:51 - 29:54
    아주 많이 달라요. 실제론 이렇게 생겼지요.
  • 29:54 - 30:08
    저기 많은 컨트롤러들이 있지요. 웹 환경에서는 저 컨트롤러들은 웹에 의해 작동됩니다.
  • 30:08 - 30:21
    저 구름 너머에 있는 웹 프레임워크지요. Rails 일지 Spring일지 어떤 것이든지 상관없어요. 어째됬건 그 복잡하고 끔찍한 URL을 전달해서 컨트롤러에 전달합니다.
  • 30:21 - 30:34
    웹으로 부터 받은 변수와 데이터를 컨트롤러에게 전달합니다. 그러면 컨트롤러들은 비지니스 오브젝트들에게 와서 어떤 일을 하라고 소리를 칩니다.
  • 30:34 - 30:45
    그리고 비지니스 오브젝트로 부터 데이터를 모아서 뷰에게 이야기합니다. 그러면 뷰들은 다시 비지니스 오브젝트들에게서 데이터들을 조회하고 화면에 표시합니다.
  • 30:45 - 30:56
    그러면 결국에는 비지니스 오브젝트들은 컨트롤러나 뷰가 가질법한 펑션들로 채워지며 결국 오염되게 됩니다.
  • 30:56 - 31:06
    펑션의 적절한 위치를 찾기가 힘들어져서 비지니스 오브젝트에 놓이면 안되는 펑션들을 비지니스 오브젝트에 구현하기도 합니다.
  • 31:06 - 31:13
    그럼 출력 쪽은 어떻게 처리할까요?
  • 31:10 - 31:31
    여기 Interactor는 일을 끝냈습니다.
  • 31:13 - 31:17
    유즈케이스를 끝내면서 데이터를 조회했지요. 생성된 Response Model을 출력 인터페이스를 통해서 막 전달하려는 시점입니다.
  • 31:32 - 31:37
    저 출력 인터페이스는 어떤 것이 구현할까요? Presenter라 불리우는 것 입니다.
  • 31:37 - 31:45
    Presenter의 역할은 순수 데이터 구조인 Response Model을 받아서
  • 31:45 - 31:52
    View Model이라는 또다른 데이터 구조로 변형시킵니다.
  • 31:52 - 32:03
    View Model은 출력의 모델입니다. 출력 값을 표현하는 것이고 여전히 순수한 데이터 구조입니다.
  • 32:03 - 32:11
    하지만 화면에 표가 있다면 View Model에도 표가 있을 겁니다.
  • 32:11 - 32:17
    화면에 텍스트 필드가 있다면 View Model에도 텍스트 필드가 있을겁니다.
  • 32:17 - 32:28
    화면의 숫자를 소수점 이하 두 자리수 까지만 표현하겠다면 ViewModel은 TrimToTwoDecimalPlaces와 ConvertIntToString라는 메소드를 가지게됩니다.
  • 32:28 - 32:38
    음수인 경우 괄호로 표현하게 되었다면 Presenter가 괄호를 붙여서 View Model에 저장을 하게됩니다.
  • 32:38 - 32:43
    메뉴 아이템들이 있다면 그 이름들도 View Model에 저장이 됩니다.
  • 32:43 - 32:53
    비활성화된 메뉴 아이템들은 회색으로 처리되어야 한다면 View Model에는 불린 값으로 저장이 됩니다.
  • 32:53 - 33:04
    화면에 표시되는 모든 것들은 View Model에 저장이 됩니다. 여전히 추상화된 방식으로요.
  • 33:04 - 33:08
    그리고는 View에 입력이 됩니다.
  • 33:08 - 33:16
    View는 멍청해요. View는 저것들과 아무런 관련이 없고요 단순히 View Model로 부터 데이터를 가져갑니다.
  • 33:16 - 33:21
    아무 것도 처리하지 않습니다. If 구문도 없고요 아마 테이블을 표시하기 위한 루프문 정도는 있겠지요. 이정도가 다 입니다.
  • 33:21 - 33:29
    View는 아주 멍청해서 신경쓸 이유가 없습니다. 일반적으로 테스트도 잘 안하지요. 어찌되었건 우리 눈으로 보게되니까요.
  • 33:29 - 33:33
    Presenter를 테스트 할 수 있을까요?
  • 33:33 - 33:39
    할 수 있지요. Request Model을 건넨 후에 View Model 데이터를 기다리면 됩니다.
  • 33:39 - 33:44
    Presenter를 테스트 할 때에 웹 서버가 실행되어야 할까요?
  • 33:44 - 33:49
    아니지요. 웹 서버가 없어도 모두 테스트할 수 있습니다.
  • 33:49 - 33:53
    스프링 같은 컨테이너들을 실행할 필요도 없지요.
  • 33:53 - 33:56
  • 33:56 - 34:00
    간단하게 순수 오브젝트를로 테스트가 가능합니다.
  • 34:00 - 34:07
    그나저나 이게 목표입니다. 다른 아무것도 실행시키지 않고 가능한 많은 테스트를 하는 것 입니다.
  • 34:07 - 34:13
    30초에서 1분 정도나 걸려서 이 서저 저 서버를 시작시키지 않아도 됩니다.
  • 34:13 - 34:19
    다른 건 필요 없이 테스트만 실행할 수 있으면 됩니다. 저중 아무 것도 필요 없이 가능한 빠르게 착착착 끝내면 됩니다.
  • 34:19 - 34:25
    저게 합쳐 놓은 그림입니다.
  • 34:25 - 34:32
  • 34:32 - 34:37
  • 34:37 - 34:49
  • 34:49 - 34:54
  • 34:54 - 35:00
  • 35:00 - 35:05
  • 35:05 - 35:11
  • 35:11 - 35:21
  • 35:21 - 35:30
  • 35:30 - 35:34
  • 35:34 - 35:39
  • 35:39 - 35:50
  • 35:50 - 35:54
  • 35:54 - 36:03
  • 36:03 - 36:15
  • 36:15 - 36:26
  • 36:26 - 36:28
Title:
Robert C. Martin - Clean Architecture and Design
Description:

more » « less
Video Language:
English
Duration:
01:05:41

Korean subtitles

Revisions Compare revisions