5분 안에 알게 될 거야...그렇게 지도 모른다, 아마, 아마...청결 구조

3527 단어 청결 구조tech

목표


청결 체계 구조를 5분간 대략적으로 설명하는 것이 목적이다.
※ 구성, 앞서 읽은 책.남겨진 기억에서 이야기의 줄거리만 정리할 수 있다면 Try!

설명


청결한 건물을 들어본 사람과 들어보지 못한 사람은 먼저 아래의 그림부터 시작한다.

원재료는 The Clean Code Blog로 책화된 것이 유명하다Clean Architecture가 사람들에게 배운 소프트웨어의 구조와 디자인(아스키 DWANGO)
이 그림과 책에 관해 다양한 설명을 시도했지만, 기본적으로 아래의 말만 한 것으로 이해할 수 있다.
  • 가급적 변경하지 않으려는 것을 중심으로 다른 층이 중심에 의존하는 방식으로 배치
  • 의존하는 프로세스 센터.그러나 통제하는 절차도 중간에서 밖으로
  • 할 말이 정말 이만큼밖에 없어요.

    중심에 의존?


    어셈블리 A와 어셈블리 B가 A->B에 의존하는 경우 B가 변경되면 A에 영향을 줍니다.
    그러니까 수정해야 할 수도 있다는 거야.시험을 봐야 할지도 몰라요.
    그래서 "변경하고 싶지 않은 것을 의존하는 쪽에 두면 변경이 강해진다!"이렇게 말해도 되죠!
    따라서 그림의 예에서 DB->Gateway->Usecase로 설정하여 DB 변경으로 인해 Usecase의 코드가 더 잘 수정되는 것을 방지한다.
    앞서 설명한 바와 같이, "그러나 Usecase는 DB를 사용합니다. 사용은 그것에 의존하지 않습니까?"그렇게 생각하는 사람.
    이에 맞서는 도구는'의존관계 역전의 원칙'이며, 이를 디자인에 사용함으로써'사용','호출'등 제어 프로세스와 의존관계와 분리할 수 있다고 저자는 알려준다.
    의존관계 역전의 원칙에 대한 설명은 서적이나여기.의 설명으로 보면 이해하기 쉽다.
    의존 관계의 반전 원칙을 사용함으로써 인터페이스에 의존하는 의존적 방향의 조작을 실현할 수 있다.이것은 구성 요소 간의 의존성을 이용하여 별로 바꾸고 싶지 않은 구성 요소와 중요한 구성 요소에 의존하도록 설계할 수 있다.
    이렇게 하면 변경에 매우 저항력이 있다고 말할 수 있다.이것은 좋은 구조 원칙이 아닌가?나는 이것이 일종의 청결 체계 구조라고 생각한다. 작가가 하고 싶은 말이다.

    생각


    설계된 물건은 설치할 수 있기 때문에 최신 설치 방법이 매우 궁금하다.
    그러나 작가도 책 속에 있다
      若いプログラマ は「そんなわけがない」と言うかもしれない。昔は昔、今は今。過去のルールが 今でも通用するわけがないと思うのだろう。もしそう考えているのなら、残念ながら間違っている。ルールは何も変わっていない。言語やフレームワークやパラダイムがまったく新しいものに変わったところで、ルール自体はAlan Turingが最初のマシンコードを書いた1946年と同じままだ。でも、ひとつだけ変わったことがある。かつての我々は、そのルールがどんなものかを知らなかった。 そのせいで、 何度となくルールを破ってきた。今は違う。半世紀の経験を経て、我々はようやくルールをつかんだ。   時代を超越した不変のルールたち。それこそが本書のすべて だ。
    
    Robert C.Martin; 角 征典; 高木 正弘. Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) (Kindle の位置No.318-324). 株式会社ドワンゴ. Kindle 版. 
    
    원리원칙을 말하려면읽는사람도그럴 생각이다.내가만든것을 내려다보면대체로처음그림처럼의존관계가된다면좋겠다!나는 이렇게 하면 된다고 생각한다.

    소상2


    자기만족을 위해서?그런 것도 아니고.실제 체험을 보면, 나는 이 원리의 원칙이 상당히 중요하다고 생각한다.
    예를 들어 지도 검색 서비스를 만드는 것을 고려한다.
    이때 UI-> 서비스 ->는 DB와 의존 관계를 가진다. DB팀이 준비한 API가 서비스 곳곳에 있다고 가정한다.이 상태에서 DB가 변경되면 서비스가 모두 재테스트돼 변경에 능하다고 할 수는 없다.
    누구나 디자인이 안 좋아서'영향 범위가 너무 넓어서 변경할 수 없다'고 말하거나 들어봤죠.
    이런 일이 발생하지 않도록'서비스 곳곳에서 DB를 만지지 말자'고 생각했다.
    결실
  • 통합 터치 DB 섹션
  • 통합 후 랩을 사용하는 반은 서비스의 필수품
    서비스 결정 API
    → DB를 통해 관계상 서비스를 원하는 인터페이스를 실현
  • 서비스

    생각하는 곳3


    시험에 능하다.진짜 강해.외부 구성 요소에 직접 접촉하지 않고 인터페이스가 중간에 끼어 있기 때문에 DI는 매우 수월해진다.

    좋은 웹페이지 즐겨찾기