Bob Martin의“Clean Architecture”는 모든 아키텍처의 경험 법칙입니까 아니면 옵션 중 하나입니까?

나는 밥 마틴 아저씨의 '깨끗한 건축 원리 '비디오 의 개념을 정말 좋아했습니다 . 그러나 저는이 패턴이 추상 팩토리 와 빌더 패턴의 핵심 인 것처럼 느껴집니다 .

이것은 좋은 프로그램을 작성하는 유일한 방법이지만 유일한 방법은 아닙니다.

Rails와 reactjs는 이런 종류의 깔끔한 아키텍처를 장려하지 않는 두 가지 프레임 워크입니다. Rails는 비즈니스 로직이 모델 ( FatModels 및 SkinnyControllers )에 있고 컴포넌트 내부에서 반응 할 것으로 예상합니다 . 두 가지 접근 방식 모두 비즈니스 로직 과 프레임 워크 코드를 밀접하게 결합 합니다 .

나는 세 가지 방법 중 어떤 것도 잘못 찾지 못했습니다. 어느 쪽이든 고르는 것은 심판의 소명입니다.

그러나 비디오에서 그는 깨끗한 아키텍처가 비즈니스 로직과 프레임 워크 사이에 명확한 경계를 가져야한다고 제안합니다. 프레임 워크 (웹, 안드로이드 등)는 비즈니스 로직 에 플러그인되는 플러그인이어야합니다 . 그는 비디오에서 레일을 미묘하게 조롱했습니다.

그래서, 밥 마틴 "클린 아키텍처는"모든 아키텍처를위한 엄지 손가락의 규칙 아니면 그냥 옵션 중 하나입니까?

"청결한 아키텍처"는 훌륭하고 많은 장점이 있지만 다음을 기억하는 것이 중요합니다.

• Clean Architecture는 주로 Robert C. Martin의 Jeffrey Palermo (2008)의 Onion Architecture 및 Alistair Cockburn 및 기타 (2008)의 Hexagonal Architecture ( "Ports and Adapters")와 같은 관련 접근 방식의 브랜딩 및 진화입니다.

• 문제마다 요구 사항이 다릅니다. Clean Architecture 및 관련 접근 방식은 디커플링, 유연성 및 종속성 반전을 최대 11 개로 설정하지만 단순성을 희생합니다. 항상 좋은 거래는 아닙니다.

이러한 아키텍처의 선구자는 Smalltalk의 클래식 MVC 패턴입니다. 이는 모델이 UI에 의존하지 않도록 모델을 사용자 인터페이스 (컨트롤러 및보기)에서 분리합니다. MVP, MVVM,…과 같은 MVC에는 많은 변형이 있습니다.

보다 복잡한 시스템에는 하나의 사용자 인터페이스가 아니라 여러 사용자 인터페이스가있을 수 있습니다. 많은 앱이 웹 앱 또는 모바일 앱과 같은 모든 UI에서 사용할 수있는 REST API를 제공하도록 선택합니다. 이렇게하면 서버의 비즈니스 로직이 이러한 UI와 분리되므로 서버는 액세스하는 앱의 종류를 신경 쓰지 않습니다.

일반적으로 서버는 여전히 데이터베이스 또는 타사 공급자와 같은 백엔드 서비스에 의존합니다. 이것은 완벽하게 훌륭하며 단순한 계층 구조로 이어집니다.

6 각형 아키텍처는 더 나아가 프론트 엔드와 백엔드를 구분하지 않습니다. 외부 시스템은 입력 (데이터 소스) 또는 출력 일 수 있습니다. 핵심 시스템은 필요한 인터페이스 (포트)를 정의하고 모든 외부 시스템에 대한 어댑터를 만듭니다.

강력한 디커플링을위한 하나의 고전적인 접근 방식은 모든 서비스가 공유 메시지 버스에 이벤트를 게시하고 이벤트를 사용하는 서비스 지향 아키텍처 (SOA)입니다. 비슷한 접근법이 나중에 마이크로 서비스에 의해 대중화되었습니다.

이러한 모든 접근 방식은 (모의 구현으로 인터페이스하는 모든 외부 시스템을 대체함으로써) 시스템을 독립적 으로 테스트 하기 쉽게 만드는 것과 같은 장점 이 있습니다 . 한 종류의 서비스 (예 : 두 번째 지불 프로세서 추가)에 대해 여러 가지 구현 을 쉽게 제공 하거나 서비스 구현 (예 : Oracle 데이터베이스에서 PostgreSQL로 이동 또는 Go에서 Python 서비스를 다시 작성 )을 교체 할 수 있습니다. .

그러나 이러한 아키텍처는 아키텍처의 페라리입니다. 비싸고 대부분의 사람들은 필요하지 않습니다. Clean Architecture 등의 추가 유연성은 더 복잡한 비용이 듭니다. 많은 응용 프로그램, 특히 CRUD 웹 응용 프로그램은 그 이점을 얻지 못합니다. 템플릿을 사용하여 HTML을 생성하는 등 변경 될 수있는 사항을 격리하는 것이 좋습니다. 예를 들어 백업 데이터베이스와 같이 변경되지 않는 것을 격리하는 것은 의미가 없습니다. 변경 될 가능성은 상황과 비즈니스 요구에 따라 다릅니다.

프레임 워크는 변경 될 사항에 대한 가정을합니다. 예를 들어 React는 구성 요소의 디자인과 동작이 함께 변경된다고 가정하는 경향이 있으므로 구성 요소를 분리하는 것은 의미가 없습니다. 프레임 워크를 변경하고자하는 프레임 워크는 거의 없습니다. 따라서 프레임 워크에는 많은 양의 잠금이 있습니다. 예를 들어 (매우 의견이 많은) Active Record 패턴에 대한 Rail의 의존은 데이터 액세스 전략을 (종종 우월한) 리포지토리 패턴으로 변경하는 것을 어렵게 만듭니다. 변경에 대한 기대치가 프레임 워크와 일치하지 않으면 다른 프레임 워크를 사용하는 것이 좋습니다. 다른 많은 웹 프레임 워크는 데이터 액세스에 대한 가정을하지 않습니다.

나는 밥 마틴 아저씨의 '깨끗한 건축 원리'비디오의 개념을 정말 좋아했습니다. 그러나 저는이 패턴이 추상 팩토리와 빌더 패턴의 핵심 인 것처럼 느껴집니다.

근처에도 안.

당신이 이것을 볼 때 :

개체 그래프의 디자인을보고 있습니다. 이것은 무엇에 대해 아는 것을 지시합니다. 이 이야기에서 빠진 것은 그 객체 그래프가 어떻게 만들어 졌는가입니다. 죄송하지만 여기서 찾을 수 없습니다. 건축에 대한 언급은 없습니다.

추상 팩토리 및 빌더없이이 모든 것을 구성 할 수 있습니다. 내가했기 때문에 알고 있습니다 . 나는 그들을 피하기 위해 출발하지 않았다. 나는 그들을 사랑합니다. 난 그냥 그들을 필요로하지 않았다. 방금 참조 전달을 사용했습니다. 의존성 주입 은 멋진 용어입니다.

사실, 그 다이어그램에 보이는 모든 것을 기본으로 만들 수 있습니다. 그런 다음 하나의 객체에서 하나의 메소드를 호출하여 모든 항목을 시작하십시오.

이제 물건을 다른 물건에 밀어 넣으려면 먼저 물건이 있어야합니다. 나는 그것을 여기에서 탐구 하고이 귀여운 작은 다이어그램을주었습니다.

그리고 떠나지 않고도 모든 것을 만들 수 있습니다 main().

절차 적 구성 코드 더미를 적당한 크기의 개념적 덩어리로 나누고 싶을 때 빌더와 팩토리를 사용하는 것이 좋습니다. 그러나 깨끗한 아키텍처 나 다른 전문 용어는 없습니다. 따라서 고집하고 싶다면 main()괜찮습니다. 다만, 제발 자비를 베푸소서 .

Bob Martin의“Clean Architecture”는 모든 아키텍처의 경험 법칙입니까 아니면 옵션 중 하나입니까?

나는 Clean Architecture를 사람들을 블로그와 책으로 몰아 넣는 데 사용되는 용어로 간주합니다. 이 블로그와 책은 사람들을 오래된 블로그와 오래된 책으로 몰아 넣는 데 사용되는 오래된 이름을 가진 매우 유사한 오래된 아키텍처에 대해 잘 설명되어 있습니다. 포트 및 어댑터뿐만 아니라 특히 양파. 유일한 건축 옵션은 없습니다.

밥 삼촌은 훌륭한 대중 연설자이자 저자이기 때문에 좋아합니다. 그는 내가 달리 가질 수없는 것들을 생각하게한다. 그러나 당신이 그것을 당신이 종교적인 열의로 바꾸게하면 모든 것이 그의 방식으로 이루어져야한다고 주장하면 문서를 업데이트하는 것이 가장 가까운 코드라는 것을 빨리 알게 될 것입니다.

버즈 워드 아키텍처는 세상이 바뀌면서 오래 지속되어야하는 코드를 오래 살았을 때 유용합니다. 그때가 빛납니다. 코드와 비교하여 세상이 안정적이라면 아무런 이유없이 멋진 것을 만들고 있습니다.

아무리 멋진 일이 있어도 터무니없는 상황을 만들 수 있습니다. 죄송합니다, 이것은 은색 총알도 아닙니다.

그러나 비디오에서 그는 깨끗한 아키텍처가 비즈니스 로직과 프레임 워크 사이에 명확한 경계를 가져야한다고 제안합니다. 프레임 워크 (웹, 안드로이드 등)는 비즈니스 로직에 플러그인되는 플러그인이어야합니다. 그는 비디오에서 레일을 미묘하게 조롱했습니다.

네가 옳아. 그는 그렇습니다. Bob 아저씨는 프레임 워크를 라이브러리처럼 취급 할 수 있다고 생각합니다. 그리고 그들은 할 수 있습니다. 그러나 그 결정조차도 비용이 든다.

Martin 씨가 보존하려고하는 것은 범용 언어가 여전히 일반적인 공간입니다. 프레임 워크를 어디에나 퍼뜨릴 때 포기합니다. 그렇게하면 언어를 도메인 특정 언어라고 부르는 경로로 향하게됩니다. HTML은 도메인 특정 언어입니다. 그것은 잘 작동하지만 전혀 할 수없는 다른 일이 있습니다.

프레임 워크에서 요구 사항을 예상하는 한 매우 원활하게 진행됩니다. 당신의 요구를 예상하는 것이 좋습니다. 물건을 간단하게 보관하는 상자에 넣습니다. 이것을 얻기 위해 무엇을 포기하는지 이해하십시오. Spring을 어디에나 퍼 뜨리면 더 이상 Java 작업으로 광고 할 수 없습니다. Java / Spring 작업입니다. Ruby와 Rails에 대해 같은 것을 말할 수 있지만 Rails는 오래 전에 Ruby의 점심을 먹었습니다.

비디오를 인용하려면 :

"SQL에서 편지 병합을하고 싶지 않습니다."

뒤에 :

"실제로 편지 병합 전체 인 SQL 저장 프로 시저를 보았습니다"

메일 병합과 같은 아키텍처는 많은 옵션 중 하나 일뿐입니다.

선택적이 아닌 것은 아키텍처가 해결하려고하는 문제입니다.

SQL 편지 병합으로 인해 발생하는 문제를 다른 솔루션과 비교하면 아키텍처 선택에 대한 정보가 제공되며 '나쁜'솔루션을 선택해야하는 경우에도 부족한 부분을 알고 완화 할 수 있습니다.

잘 생각해서 건축 양식을 따르는 경우 실수를 저지르고 같은 문제가 발생할 수 있습니다.

"청결한 아키텍처"는 분명히 "옵션"중 하나입니다. 나는 그것이 대부분의 프로젝트, 특히 객체 지향 프로젝트에 대한 나쁜 옵션 중 하나 라고 주장합니다 .

Clean Architecture에 대한 Bob Uncle의 기사에 대한 문장 별 문장 분석은 다음과 같습니다.

객체 지향 관점에서 깨끗한 아키텍처

Clean Architecture는 소프트웨어 개발 조직이 복잡한 응용 프로그램을 구축하는 동안 종종 직면하는 여러 일반적인 증상을 해결하기위한 일련의 원칙과 패턴입니다. Martin은이 분야에서 광범위한 경험을 바탕으로 증상과 근본 원인을 파악하고 이러한 우려를 완화하는 데있어 아키텍처의 역할을 명확히하기 위해이 책에서 많은 시간을 들였습니다.

그러나 그것은 엄지 손가락의 법칙이 아니며 모든 병에 대한 만병 통치약이 아닙니다. 이 책을 읽으면, 그가 옹호하는 원칙과 패턴을 적용 할 것인지 / 언제 / 어떻게 적용하는지 (및 관련된 상충 관계)를 더 잘 이해할 수 있습니다. 이 책을 읽지 않으면 불완전한 정보를 바탕으로 잘못된 가정, 적용, 판단 및 진술을 할 수 있습니다.