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
  • 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
  • 23:37 - 23:51
  • 23:51 - 23:53
  • 23:53 - 23:57
  • 23:57 - 24:02
  • 24:02 - 24:11
  • 24:11 - 24:27
  • 24:27 - 24:33
  • 24:34 - 24:42
  • 24:42 - 24:48
  • 24:48 - 25:01
  • 25:01 - 25:11
  • 25:11 - 25:15
  • 25:15 - 25:20
  • 25:20 - 25:25
  • 25:25 - 25:30
  • 25:30 - 25:33
  • 25:33 - 25:41
  • 25:41 - 25:45
  • 25:45 - 25:51
  • 25:51 - 25:57
  • 25:57 - 25:58
  • 25:58 - 26:06
  • 26:06 - 26:14
  • 26:14 - 26:18
  • 26:18 - 26:28
  • 26:28 - 26:35
  • 26:35 - 26:41
  • 26:41 - 26:47
  • 26:47 - 26:50
  • 26:50 - 26:58
  • 26:58 - 27:01
  • 27:01 - 27:06
  • 27:06 - 27:13
  • 27:13 - 27:19
  • 27:19 - 27:28
  • 27:28 - 27:30
  • 27:30 - 27:42
  • 27:42 - 27:48
  • 27:48 - 27:59
  • 27:59 - 28:01
  • 28:01 - 28:07
  • 28:07 - 28:15
  • 28:15 - 28:24
  • 28:24 - 28:36
  • 28:36 - 28:40
  • 28:40 - 28:50
  • 28:50 - 29:01
  • 29:01 - 29:04
  • 29:04 - 29:15
  • 29:15 - 29:24
  • 29:24 - 29:29
  • 29:29 - 29:38
  • 29:38 - 29:43
  • 29:43 - 29:51
  • 29:51 - 29:54
  • 29:54 - 30:08
  • 30:08 - 30:21
  • 30:21 - 30:34
  • 30:34 - 30:45
  • 30:45 - 30:56
  • 30:56 - 31:06
  • 31:06 - 31:13
  • 31:10 - 31:31
  • 31:13 - 31:17
  • 31:32 - 31:37
  • 31:37 - 31:45
  • 31:45 - 31:52
  • 31:52 - 32:03
  • 32:03 - 32:11
  • 32:11 - 32:17
  • 32:17 - 32:28
  • 32:28 - 32:38
  • 32:38 - 32:43
  • 32:43 - 32:53
  • 32:53 - 33:04
  • 33:04 - 33:08
  • 33:08 - 33:16
  • 33:16 - 33:21
  • 33:21 - 33:29
  • 33:29 - 33:33
  • 33:33 - 33:39
  • 33:39 - 33:44
  • 33:44 - 33:49
  • 33:49 - 33:53
  • 33:53 - 33:56
  • 33:56 - 34:00
  • 34:00 - 34:07
  • 34:07 - 34:13
  • 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