청결 구조와 MVP에 대한 생각

최초 발표WahibHaq blog.
약 3개월 전, 나는 안드로이드 개발자 직위의 구직 과정을 겪고 있으며, 각종 면접 절차를 겪었다.한 잠재적 고용주가 나에게 다음과 같은 상황에 대한 구조 제안을 제출하라는 임무를 주었다.

You are an experienced developer. Can you design 1-page architecture of an app
for a financial product with 50k users base (3k daily), that can work in a
modern setup of development, e.g. Spotify squads? Once you come onboard you may have to design for 10-100x userbase. The architecture can be a generic view.

나는 나의 개인적인 생각을 연구하고 문서로 정리했다.오늘 나는 그것들을 블로그로 발표하기로 결정했다.

Disclaimer: Detailed explanations of Clean Architecture or MVP are not provided in this post as it is only highlighting the proposed solution and outlining my reasoning behind it.

한편, 2017년은 제가 Clean Architecture에 흥미를 느낀 해입니다. Model-View-Presenter (MVP)의 안드로이드 응용 프로그램에서 응용Freeletics 구조 모델을 활용하여 실천 경험을 얻었습니다.전반적으로 말하자면 소프트웨어 구조는 줄곧 내가 흥미를 느끼는 분야이다. 불행하게도 나는 과거의 어떤 안드로이드 프로젝트에서도 그것을 실현할 기회가 없었다.안드로이드 개발자들은 신뢰할 수 있는 구조가 없는 상황에서 건장하고 질이 높으며 유지보수가 가능한 응용 프로그램을 구축하는 어려움을 이해한다.
흥미로운 것은 2017년 구글officially이 처음으로 안드로이드 앱 사용app architecture을 추천하면서 사람들은 이 한 해를 영원히 기억할 것이다.이것은 기본적으로 하나의 라이브러리의 집합으로 간단하고 유연하며 실용적인 방법을 제공하여 개발자들이 흔히 볼 수 있는 문제에서 해방되도록 한다. 그러면 그들은 더욱 적은 샘플 코드로 모듈화된 응용 프로그램을 작성하고 좋은 체험을 구축할 수 있다.

아키텍처(Architecture) 구성 요소 우리는 현대 응용 프로그램 구조에서 무엇을 기대해야 합니까?

내가 보기에 그것은 건장하고 안정적이며 확장하기 쉬우며 작업량이 가장 적고 민첩한 수요에 따라 변경할 수 있으며 새로운 플랫폼 기능에 신속하게 융합되고 테스트 가능성을 지원하며 서로 다른 단계의 개발자에게 이해를 하여 유지보수성을 확보해야 한다.
나는 깨끗한 건물이 답이라고 믿는다.

깨끗한 건물

자료 출처: 8페이지.일반 도메인 이름 형식
에서 코드는 양파 모양의 층으로 나뉘는데 그 중 하나는 의존 규칙이 있다. 내부는 외부의 어떤 정보도 알지 말아야 한다.내부는 업무 논리를 포함하고 외부는 실현을 포함하며 중간층은 인터페이스 어댑터를 포함한다.각 루프는 추상적인 레이어를 나타냅니다.

Some key technical benefits achieved in this way are:

> Abstraction over Implementation
> Single Responsibility Principle 
> Separation of Concern
> Decoupled Code

깨끗한 건물 서로 다른 층, 구성 요소 및 그것들 간의 통신 방식

자료 출처: 5.기구

데모 / 사용자 인터페이스 레이어

MVP는 UI/presentation 계층에 매우 적합하다.

보기는 벙어리와 실현 모델이다.활동, 세션, 어댑터, 사용자 정의 보기 등 모든 안드로이드 보기로 이루어질 수 있는 인터페이스입니다.

프레젠테이션은 보기(Android 특정 구성 요소의 추상)와 업무 논리(상호작용자/용례) 사이의 중간자 역할을 한다.이들은 사용자 상호작용을 처리하고 적당한 업무 논리를 호출하며 데이터를 UI로 보내 렌더링합니다.

Presenter는 Android 클래스에 의존하지 않기 때문에 테스트 가능성을 높였다.

수동 뷰 도메인 계층

용례의 간단한 예는'자금을 한 계좌에서 다른 계좌로 이전하는 것'이다.모든 용례는 특정한 업무 논리를 실행하는 재사용 가능한 구성 요소이다.저장소에서 데이터를 가져와 비즈니스 논리를 수행하고 결과를 발표자에게 되돌려줍니다.

데이터 레이어(데이터베이스 및 API)

데이터 원본의 추상을 만들고 그 중에서 데이터를 가져와 조작한다.모든 숨겨진 지속성은 여기에 있어야 한다: DAOs, ORM, 개조(또는 인터넷과 관련된 다른 것들) 서비스, JSON 해석 등

흩어진 네트워크에서도 응용 프로그램은 빈틈없이 작동할 수 있어야 한다.이전에 얻은 자원을 캐시하고 다시 사용하는 능력은 성능을 최적화하는 관건적인 부분이다.

업무 논리는 데이터가 어디에서 왔는지 알아야 한다.로컬에서 실행되지만 전 세계가 동기화됩니다.

저장소 모드 장치 레이어

장치는 센서, 경보, 알림, 플레이어, 각종 관리자 등 안드로이드의 각종 실현을 포함한다.

의안 구조의 분석

깨끗한 건물을 고수한다.

모듈급, 패키지급, 클래스급으로 가지런히 분리된다.따라서 단일 책임 원칙과 이익 분리 원칙을 충족시켜야 한다.

업무 논리는 더 이상 안드로이드와 직접 접촉하지 않는다. 이것은 결합된 코드 라이브러리를 만들어 낼 것이다.

각 의존항의 시뮬레이션을 통해 분리된 클래스에 주입하면 테스트를 더욱 쉽게 할 수 있다.

프레젠테이션 논리를 처리하기 위해 프레젠테이션을 사용하도록 강요하지 않았기 때문에 깨끗한 아키텍처는 "전단"으로 알 수 없다. 이것은 우리가 MVP, MVVM 또는 기타 어떤 것도 사용할 수 있다는 것을 의미한다.

발표자는 활동에 직접 의존하지 않고 보기 인터페이스에 의존한다. 이런 방식을 통해 우리는 원칙 중의 D에 따라 발표자와 보기를 결합시키는 데 성공했다.우리는 발표자의 코드를 변경할 필요 없이 구체적인 보기를 바꿀 수 있다.그 밖에 우리는 시뮬레이션 보기를 만들어서 테스트 시연자에게 단원 테스트를 쉽게 할 수 있다.

각 층마다 자신의 모델이 있기 때문에 구체적인 세부 사항(예를 들어 보기)은 낮은 층이 실현하는 구체적인 세부 사항에 달려 있지 않다.

우리는 SOLID의 기능을 사용하여 상류에 데이터를 제공하고 층간 통신을 사용하지 않고 라인 스케줄링을 처리할 수 있다.모든 내층은 외층이 이해할 수 있는 방식으로 데이터를 변환할 수 있다.

외부 구현을 변경할 수 있으며, 우리의 코드 라이브러리를 대량으로 변경할 필요가 없으며, 확장성 요구를 만족시킬 수 있습니다.

이런 방법을 채택하는 것은 어렵고 시간이 걸리지만 코드를 작업하고 유지할 미래 개발자에 대한 도움으로 간주할 수 있다.

특히 의존 주입 프레임워크를 지원한다. 예를 들어 RxJava.

단검 다기능 팀 및 아키텍처

위에서 공유한 문제 진술도 언급했다 . 이것은 매우 재미있는 개념으로 Spotify 공학 문화에서 나온 것이다.제품 팀은 강대하고 지식이 풍부한 개발 팀을 세우는 좋은 방법인 것 같다.문외한으로 말하자면, Squad는 소형의 크로스 기능 자체로 scrum팀을 조직한다.그들은 끝까지 책임을 지고 장기적인 사명을 실현하기 위해 공동으로 노력한다.팀에서 관건적인 동력은 자율성이다.
고용주에게 민첩성은 관건적인 요구이기 때문에 민첩성을 지지하는 구조에 대한 기대이기도 하다.더 중요한 민첩성 원칙 중 하나는

“The best architectures, requirements, and designs emerge from self-organizing teams.”

Spotify Squads 팀의 프로그래머가 필요하지 않다고 생각한다.이것은 팀의 책임이다.이상적인 팀에서 모든 구성원들은 중첩되고 보완되는 문제를 생각한다.

소프트웨어 구조는 5~9명의 구성원이 함께 납품할 수 있는 기능을 실현하는 데 장애가 되어서는 안 된다.

깨끗한 체계 구조는 관심점의 분리를 제공했고 개발진에게 관리 환경에서의 복잡성과 신속한 변화에 필요한 리듬과 유연성을 제공했다.설계를 통해 구성 요소 사이에 절구를 만들고 미래의 통신을 위한 계약을 맺었다.이로 인해android 개발자는 다른 부락의 구성원들과 업무를 조율할 수 있다.

개발 기능을 시작하기 전에 정의Benji Weber의 실천은 같은 팀의android 개발자들이 그들 간의 책임 영역을 효율적으로 정의하는 데 간접적으로 도움을 준다.

MVP 계약 한층 더 읽다

What is all this Clean Architecture jibber-jabber about?

Android Architecture Series

Converting an App to Use Clean Architecture

Architecting Android...The clean way?

A complete idiot’s guide to Clean Architecture