logo

06.01

- book. 클린 아키텍쳐

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

<br>

06.02

- book. 클린아키텍쳐

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

<br/>

06.03

- lecture. toby reactive

<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.

- 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

<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

- 약속

CommentCount 0
이전 댓글 보기
등록
TOP