Machine_웅_Note

1. 도메인 주도 설계 ( DDD ) 개론 - 주된 철학 , 원리 그리고 전략적 설계 => 그프로젝트에서 의미있는 용어를 만들고 정하는 것. => 기술적인 용어 x , 도메인 용어 x , 상호 합의된 언어 => 도메인 모델을 만드는데 핵심은 사용자 스토리 이다.

강의를 통틀어서 도메인/데이터 계층 부분이 제일 중요하다고 할 수 있다.. 집중.. 1. 앱 아키텍처의 미드필더라고 할 수 있는, 도메인 계층을 어떻게 설계 할 것인가. 사고실험 ) 2번 - 보통 이렇게 시작을 한다. ( 문제는 - 앱에 구현이 어떻게 될까에 대해서는 도움이 안된다. ) 3번의 문제 - 디자인이 계속 바뀔 수 밖에 없기때문에 비효율. 4번 - 기술검토 부분 ( 재활용 x ) => 보통의 경우 데이터 설계로 시작하는 경우가 대부분인데 이렇게 되면, 앱의 경우에는 어떻게 구현을 해야할지에 대해서는 알 수 없고, 도움이 되지 않는다. Bast Case => UI와 DB 연결을 제외하고도 핵심시나리오를 구현 할 수 있기 때문에 나중에 재활용이 가능하다. => 테스트를 먼저 진행하면서 할수 있다...

* 앱 전체의 state를 하나의 머신으로 처리를 하면 어떨까..? I : (intent) 예시 ) API 요청 -> 미들 웨어 -> API 호출 -> store 저장 -> 리듀서에서 가공 -> UI 적용 => 전체 흐름에 대한 그림을 이해해는데 어려울수 있음. => 각각의 코드들이 여러군데 흩어져있임 => 로직의 복잡도가 높아지거나, 미리 염두해서 계획해야한다. => 오히려 MVVM 에서 MVI 에서 복잡하게 처리해야 할 것들을 간단하게 처리할수 있다.

https://developer.android.com/topic/architecture 앱 아키텍처 가이드 | Android 개발자 | Android Developers 앱 아키텍처 가이드 이 가이드에는 고품질의 강력한 앱을 빌드하기 위한 권장사항 및 권장 아키텍처가 포함되어 있습니다. 참고: 이 페이지는 Android 프레임워크 기본을 잘 아는 사용자를 대상으 developer.android.com 여기에 계속 MVVM 에 관련된 내용이 계속해서 다뤄질 예정이다. * 상위객체 state Holder * view는 구독을 해서 이벤트를 통보받는 형태 ( 콜백, Observable 같은거.. ) => 만약에없다면 UIstate data class 를 만들어서 관리하는게 일반적이다. =>state holde..

UI 계층 ( 프레젠테이션 계층 ) 1. MVx 의 대원칙 => Model : 단순하게 데이터 영역이 아니라. UI 로직 외에 도메인 계층에 가까운 비지니스 로직을 포함한다고 봐야 한다. => configuration change 에대해서 처리할 수 있는 체계도 필요하다 2.MVC => android robolectric unit test 어느정도 테스트를 할 수는 있지만 한계가 있다. 해결방법 1) 뷰의 분화 ( 복잡도를 낮출 수 있음 ) 2) 뷰 컨트롤러를 만든다 => 프로세스가 종료되는 것도 염두 해야한다. ( 전화가와서 백그라운드로 전환, 메모리부족, 타입아웃에러 등 ) - saveState 처리할 수 있는 로직을 만들어야 함. => 엑티비티는 컨트롤러로 아주 제한적인 일만 해야한다. ( 예를 들..

예시 => isVaild 를 테스트 하게되면 isVaild는 프라이빗이기 때문에,, public으로 바꾸지 않아야 한다. => isVaild 정책의 변경에 따라 저 코드는 문제가 될수 있다. => set , process , assert 하는 구조는 앞으로도 계속 되는 구조임으로 기억하자. => 트렌젝션을 직접 만들어서 처리를 해보는 것이 좋다. => 테스트를 통해서 나올 결과를 가지고 판단을 해야하지, 나온 결과를 또다른 조작을 통해서 판단 검증해서는 안된다. => 위에 예시에서는 createUser로 만든 계정을 아래서 db에 넣음으로써 검증을 하는 또다른 조작을 하고 있다. 완결성 : 테스트는 전부를 가지고 있어야한다, 완성되어있어야 한다. => 그 테스트케이스 안에는 테스트하고자 하는 것을 정확일..

1. 왜 테스트가 중요한가? 2. 안드로이드 테스트 종류 3. 무엇을 테스트 해야할까? ( baby step ) 4. 구글은 어떻게 테스트 하는가 ? 5. 좋은 테스트의 조건 6. 외부 의존성 처리의 원칙 7. 테스팅 안티패턴 1. 아키텍쳐 관점에서 테스트를 어떻게 구현 해야할지 2. 좋은 아키텍처를 구축하기 위해서는 전제조건으로 테스트를 어떻게 구현해야할지 알아본다 3. 테스트의 원칙 1. 왜 테스트가 중요한가? 1) 현실적인 필요성 : QA가 보다 생산적으로 일할 수 있다. 2) 좋은 설계를 촉진 : test case 를 통해서 api 를 변경시 사용성의 차이를 즉시 알 수 있다. => 개방폐쇄 원칙, 단일책임원칙 등 필요없는 의존성 문제를 해결 할 수있음. 3) 코딩 생산성 : 확신을 가지고 작업가..

3. 모바일 클린 아키텍쳐 * 왜 이렇게 하는 가에 대해서 집중해서 보도록 하자 가장 높은 수준의 계층 - 도메인 계층 (유스케이스) : 비지니스 요구를 충족하기 위한 부분 * 엔티티 - 업무 룰의 정의이다 ( 데이터 저장소가 아닌다 ) * 유스케이스 - 기술적인 부분이 아니라 비지니스 로직부분 이다. 도메인 관점의 비지니스로직 : 개발자가아니라, 기획자 등이 알아야 하는 비지니스 로직을 말한다.

1. 복잡성 제거 - 좋은 설계를 위한 첫 걸음 1) 복잡성을 조장하는 요인 세가지 - 의존성 ( 코드가 독립적으로 이해되고, 수정 될 수 없을때. -> 없앨수는 없으나 최소화해야함. ) - 불명확성 ( 중요한 정보가 불명확할 때 - 특정 메소드의 인풋 아웃풋이 불명확 , 과정이 불명확 ) - 전술적 프로그래밍 ( 전략적 프로그래밍 ) ( 빨리 완성하기 - 지금 있는 문제만 고려하고 수정하는 문제 ) 2) 복잡성을 낮추는 방법 추상화 - 정보에 대한 간단한 시나리오나, 시놉시스만 알면되는 것 깊은 모듈 - 모듈이 있다고 가정할 때에 사용자가 알아야 하는 것은 단순하게 사용할수 있는 메서드나 클래스여야 한다 - 하나의 기능을 사용하기 위해 계속해서 모듈의 메서들을 호출하는 것은 얕은 모듈이고 깊이가 얕고 ..

run let apply also fun main(){ studyRun() } // 스코프 함수에 대해서 알아본다. fun studyRun(){ val runResult = SeoulPeople().people.run { add( People("runPack","010-3333-4444",21)) add( People("runJeon","010-4444-5555",22)) // 인스턴스가 유지되지 않는 일회성으로 사용할 때 유리 "I'm Run ~ " } val letResult = SeoulPeople().people.let { people -> // 알리아싱을 통해서 사용 기본은 it people.add( People("letPack","010-3333-4444",21)) people.add( Peo..