2020년 06월의 MIL

06.01

- book. 클린 아키텍쳐

• 컴포넌트
• 컴포넌트 응집도
  • REP - 재사용 단위는 릴리즈 단위와 같다. 컴포넌트를 구성하는 모듈들은 서로 공유하는 중요한 테마와 목적을 가지고 있다. (포함)
  • CCP - 동일한 변경의 유형에 대하여 닫혀있는 클래스들이 한곳에 묵여있어야 한다. (포함)
  • CRP - 필요하지 않은것에 의존하지마라. (배제)
  • 세 가지 규칙이 적절한 균형을 이루고있어야한다.
• 컴포넌트 결합
  • 의존성 비순환 원칙 : 컴포넌트 의존성에 순환이 있어서는 안된다.

<br>

06.02

- book. 클린아키텍쳐

• 컴포넌트 의존성
  • 의존성 비순환 원칙
    • 순환 의존성 끊기 : 의존성 역전 법칙 이용
    • 순환 의존성 끊기 : 새로운 컴포넌트 삽입
    • 흐트러짐 : 컴포넌트간의 의존성은 개발과정에서 지속적으로 바뀐다.
  • 안전성 의존 법칙 (안정된 방향으로 의존하라)
    • 의존이 되는 컴포넌트는 더더 안정되어진다.
    • 덜 안정적인것이, 더 안정적인 것에 의존하게 하라.

<br/>

06.03

- lecture. toby reactive

• 와 리액티브.. 어렵다..
• study repo - https://github.com/cglee079/toby-reactive-study
• 1강 - https://www.youtube.com/watch?v=8fenTR3KOJo&t=4609s
• 2강 - https://www.youtube.com/watch?v=DChIxy9g19o
• 3강 - https://www.youtube.com/watch?v=Wlqu1xvZCak

<br/>

06.04

- lecture. toby reactive

• 1 ~ 3강 다시 복습.

- 회식

<br/>

06.05

- project. helloprice

• helloprice-web 구현 시작

<br/>

06.06 ~ 06.09

- 여행

<br/>

06.10

- book. 클린아키텍쳐

• 15장. 아키텍쳐란?
  • 아키텍쳐가 프로그램 작업을 지속해야하는 이유는, 발생하는 문제를 경험해보지 못하면, 다른 프로그램을 지원하는 작업을 제대로 수행하지 못하기 때문이다
  • 좋은 아키텍트는 세부사항에 대한 결정을 가능한 한 오래 미루도록 설계하는것이다
• 16장. 독립성
  • 시스템의 아키텍처는 시스템의 의도를 지원해야 한다.
  • 시스템의 아키텍처는 처리량과 응답성을 보장해야 한다.
  • 개발 : 각 팀이 독립적으로 개발가능한 단위로 분리
  • 배포 : 적절하게 분리함으로써, 즉각적인 배포를 목표
  • 수평적 분리 : UI / 업무 로직 / 세부사항
  • 수직적 분리 : 유스케이스간 ex) 장바구니 / 주문
  • 중복 : 중복을 제거하고싶은 욕구, 하지만 우발적중복이라면 중복을 유지하자.
  • 우발적중복 : 서로다른 유스케이스지만 똑같은 UI 라면 중복을 허용할것인가?

<br/>

06.11

- project. helloprice

• web 개발 진행중

- lecture. toby reactive

• 4강 수강중

- book. 클린아키텍쳐

• 17장. 경계 선긋기
  • 인적자원의 효율이 떨어뜨리는 요인은 결합이다.
  • 특히 너무 일찍 결정된 결합이다. 프레임워크, 데이터베이스, 웹서버 등..
  • 좋은 시스템 아키텍처란 이런 결정에 의존하지 않고, 결정을 최대한 미루는 것이다.
  • 경계를 긋자, 업무규칙과 데이터베이스에 경계를 그어보자. 경계를 그은 아키텍쳐는 추후 쉽게 DBMS를 바꿀수 있을 것이다.
  • 경계선을 어떻게 긋는가?
  • 핵심 업무규칙 컴포넌트를 분리한다.
  • 나머지 컴포넌트는 핵심업무규칙 컴포넌트 방향으로 의존한다. 의존성 역전을 이용하자, 저수준에서 고수준으로..!

<br/>

06.12

- lecture. toby reactive

• 4강 수강완료
  • webFlux 기본 베이스 이해완료.

- book. 클린아키텍쳐

• 18장. 경계 해부학

  • 적절한 위치에 경계를 횡단하게하는것은 소스코드 의존성 관리에 있다.

• 19장. 정책과 수준

  • 좋은아키텍쳐란 저수준 컴포넌트가, 고수준 컴포넌트에 의존하게하는것이다.
  • 그럼 수준은 무엇인가? 수준을 엄밀히 말하면 입력과 출력의 거리다.
  • 입출력과 가까울수록 저수준, 멀수록 고수준이다.
  • 소스코드의 수준은 그 수준에 따라 결합되어야하지, 데이터 흐름을 기준으로 결합되면 안된다.
  • 고수준 정책은 덜빈번하게 변경되며, 보다 중요한 이유로 변경된다.

<br/>

06.13 ~ 06.14

- 약속

<br/>

06.15

- book. 클린아키텍쳐

• 20장. 업무 규칙
  • 업무규칙은 소프트웨어의 존재이유이다. 업무규칙은 핵심적인 이유이다.
  • 업무규칙은 저수준의 관심사에 오염되지 않아야하며, 원래 그대로 남아있어야한다.
  • 업무규칙은 시스템에서 가장 독립적이며, 가장 많이 재사용 할 수 있는 코드이다.
  • 엔티티
    • 핵심 업무데이터를 기반으로, 핵심업무규칙을 구체화한다.
    • 엔티티는 오염되어있지 않아햐며, 독립적으로 존재해야한다.
  • 유스케이스
    • 입력과, 출력 그리고 해당 출력을 생성하기 위한, 처리단계를 기술한다.
    • 엔티티와 반대로 유스케이스는 어플리케이션에 특화된 업무규칙을 설명한다.
    • 유스케이스는 엔티티내
    • 부에 핵심업무규칙을 언제, 어떻게 호출할지를 명시하는 규칙을 담는다.
  • 엔티티는 고수준이며, 유스케이스는 저수준이다.
    • 유스케이스는 단일 어플리케이션이면, 입력/출력과 보다 가깝게 위치한다.
    • 따라서 유스케이스에서 엔티티로의 의존해야한다.

<br/>

06.16

- job.

• fido 지옥
  • https://fidoalliance.org/

- project. helloprice

• web 개발
  • firebase 연동 푸시 테스트

<br/>

06.17

- lecture. toby reactive

• 4강 수강 완료

- book. 클린아키텍쳐

<br/>

06.18

- lecture. toby reactive

• 5강 수강 완료

<br/>

06.19

- 약속.

<br/>

06.20

- project. helloprice

• v3.0 배포 준비중

<br/>

06.21

- project. helloprice

• v3.0 배포 완료

<br/>

06.22

- 약속.

<br/>

06.23

- book. 클린아키텍쳐

<br/>

06.24

- book. 클린아키텍쳐

- lecture. Event Sourcing과 Fintech Platform

• https://youtu.be/1QH6rKSGvY4

<br/>

06.25

- project. helloprice

• 안드로이드 크롤링 서포트

<br/>

06.26

- 약속

<br/>

06.27

- blog.

• 친절한 sql 튜닝 발행

<br/>

06.28

- project. helloprice

• orcale cloud 에 헬로프라이스 agent 배포진행하였으나
• 카프라 broker host name 이슈 때문에 실패.

<br/>

06.29

- project. helloprice

• 퇴근 후, 팀원들과 회의 진행
• 기능 명세 정리, 메인 화면 UI/UX 디자인

<br/>

06.30

- 약속