Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Share] 우아한테크세미나 - 우아한객체지향(190620 #1

Open
joomanzi opened this issue Jan 12, 2020 · 5 comments
Open

[Share] 우아한테크세미나 - 우아한객체지향(190620 #1

joomanzi opened this issue Jan 12, 2020 · 5 comments
Labels
Share This issue is about sharing things related with study

Comments

@joomanzi
Copy link

joomanzi commented Jan 12, 2020

Topic

https://www.youtube.com/watch?v=dJ5C4qRqAgA
내용에 대한 요약 정리입니다. 발표 순서랑 무관하게 정리했습니다!

Detail

1. 개발의 어려움

개발이 어려운 점은 메모리 상에서 돌아가는 동적인 구조. 변화 무쌍한 모든 가능성을 정적인 코드로 담아야한다.
그러기 위해서는 정적인 무언가를 '추상화' 하여야하고 '관계'를 정의해서 '설계'를 해야한다.

  1. 추상화
    덜 변하는 것(이 표현이 좋았음)
    상대적으로 다른 객체보다 더 추상화 됐다는 말은 다른 객체보다 덜 변한다는 뜻을 내포함

  2. 관계
    관계에는 방향성이 중요하다. 관계의 방향은 협력의 방향이며, 런타임에 어떻게 협력하는지를 통해 방향을 정의할 수 있다.

  • 관계의 종류: 상속, 실체화, 연관, 의존
  1. 설계
    무엇이 맞는 설계인가? 디펜던시 그림을 통해서 확인한다. cycle이 생기면 이를 제거할 필요가 있음.
    주로 객체들이 어떻게 협력을 하고, 메소드가 올바른 위치에 있는지 확인을 함.
    디펜던시를 그리고 의존성관점에서 검토
    패키지가 잘나눠져 있는가는 도메인 관점에서 검토(여기서 도메인은 같이 변하는 것인가로 정의)

2. 나쁜 설계의 문제점

객체참조로 인한 결합도 증가, 패키지 의존성 사이클 존재와 같은 대표적인 문제점이 있음.

1) 객체참조로 인한 결합도 증가
(1) 문제점

객체참조로 연관구현을 만들면 성능이슈가 발생하기 쉽다. (강사는 lazy loading을 언급함. 여러 객체를 순차적으로 참조할 때 발생하는 이슈를 의미하는 것 같음)

  • db, infra에 접근하다 보면 성능이슈가 매우 커짐.
  • 내 모든 작업의 경계가 롱트랜잭션의 경계로 물리게 된다. 트랜잭션의 문제가 생김.
    (어디까지 코드를 읽어야하느냐, 이런 질문들 나도 해본적있음. 비즈니스 로직을 따라가다보면 너무 많은 외부모듈, 객체 등을 참조하고 있는 경우가 많음. 결국 전체 코드를 읽는 것을 포기하게 됨..)
    -트랜잭션의 경합은 응답성을 떨어트리고, 성능 저하를 일으킨다.
(2) 해결방법

실무에서 객체관계를 제거하는 것은 매우 힘들다. 이를 위해 몇가지 기준이 있음. 하나의 트랜잭션은 도메인 룰을 통해서 정의한다.

  • 라이프 사이클
  • constraints
  • 조회의 단위

이렇게 되면 트랜잭션 단위로 데이터베이스를 분리할 수 있음.
(내 생각: db를 분리할 수 있다는 말은 MSA입장에서 마이크로 서비스로 분리할 수 있다는 의미랑 동일한 것 아닌가?)

2) 패키지간의 의존성 사이클 존재
(1) 문제점

의존성 사이클이 존재한다는 것은, 하나의 패키지가 바뀔 때 사이클 내 패키지 모두에 변경가능성이 생긴다는 것.
또 상태를 공유할 가능성이 있어짐. 이는 status를 계속해서 sync를 맞춰야하는 문제가 생기는데 시스템이 커지면서 요청이 증가하면 시스템이 연쇄적으로 죽는다.

(2) 해결방법

사이클이 생길때 해결방법 3가지

  • 하나는 좀 더 추상적인 중간객체를 만들어서 변환하는것(예제에서는 repository 사용)
  • 인터페이스나 추상화를 넣어서 의존성을 역전시키는것
  • 패키지를 찢는 방법.(도메인에 따라서 나누고, 이를 통해 응집도를 높임)
    (이 부분은 코드 예시를 좀 더 보고싶음)
@joomanzi joomanzi added the Share This issue is about sharing things related with study label Jan 12, 2020
@joomanzi
Copy link
Author

회사 업무랑 빗대어서 생각했을 때)
자바스크립트의 경우 모든 module.export한 객체가 싱글톤으로 시스템상에 존재한다.
모든 객체가 다른 객체에 접근가능하다는 의미 -> 사이클이 많이생긴다, 싱크문제가 발생할 수 있다.
다른 언어와 다르게 이를 제약하는 다른 문법이 없다.

현재 각 모듈들이 점점 커지면서 비즈니스로직이 계속해서 늘어나고 있음.
하나의 로직처리를 위해 참조해야하는 모듈이 증가하고, 하나의 트랜잭션으로(async) 묶여있음
엄청 서비스가 느림. 도메인 이벤트형식으로 이를 개선할 방법을 찾으면 좋을 것 같음.

@ttkmw
Copy link

ttkmw commented Jan 12, 2020

좋네요! 그런데 제목을 '우아한 객체지향'으로 바꾸는 게 좋지않을까 합니다~ 우아한테크세미나는 엄청많아가지고...

@hihiboss
Copy link
Member

@joomanzi @inDlife
원제목인 [우아한테크세미나] 190620 우아한객체지향을 따서 [Share] 우아한테크세미나 - 우아한객체지향(190620) 정리 어떠십니까 ㅎㅎ
근원이형 의견에 동의하는게 우아한테크세미나는 거의 시리즈라서...ㅎㅎ

@hihiboss
Copy link
Member

hihiboss commented Jan 13, 2020

이렇게 되면 트랜잭션 단위로 데이터베이스를 분리할 수 있음. (내 생각: db를 분리할 수 있다는 말은 MSA입장에서 마이크로 서비스로 분리할 수 있다는 의미랑 동일한 것 아닌가?)

-> MSA의 마이크로 서비스 분리도 비슷하지만 DDD의 도메인을 분리한다와도 비슷한 의미라고 생각합니다. DB를 분리한다는 말은 어떤 의미일지 스터디 이후에도 이야기해봅시다 :)

@joomanzi joomanzi changed the title [Share] 우아한 테크 세미나 정리 [Share] 우아한테크세미나 - 우아한객체지향(190620 Jan 14, 2020
@joomanzi
Copy link
Author

@hihiboss @inDlife
글 제목 수정하였습니다! 감사합니다~!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Share This issue is about sharing things related with study
Projects
None yet
Development

No branches or pull requests

3 participants