sung.hyun.1204 sung.hyun.1204

1. 무조건 lazy, 무조건 eager : 그런거는 없어, 경계를 잡는 방법의 차이다. 2. 연관관계를 끊자.  연관관계란 , 다른 객체를 탐색을 하는 경로로  디비 트랜잭션의 락을 전부 거는 상황이 나올수 있다.연관관계를 끊는 방법으로 객체의 다른 도메인의 속하는 객체의 id 를 넣고, 레포지토리에서 검색을 하자.레포지토리는 연관 관계를 정의하는 메서드로 이루어져 있어야 한다. 3. 도메인 에그리거트, 루트 를 생각하자.같이 생성이되는지, 같은 제약사항이 걸리는지 파악을 해야한다.같은 제약사항이 걸린다면  , 연관관계를 걸되, 다르면 그룹을 분리해서 id 로 참조하게 하여 데이터베이스 경합이 발생하는 성능 이슈를 최소화 해야한다. -> DDD  의 컨택스트를 잡는 기준이 될 수 도 있다.  왜 설계를..

이글은 테크톡의 각종 영상과 각종 블로그를 읽고 작성한다. 최종 수정 : 2023 년 10월 27일 , 최초 작성일 2023.03.27 이 글은 DTO , VO 그리고 lombok 의 @Data 를 다룬다 DTO ,VO 둘다 데이터를 저장하는 객체(Object)이다. DTO는 데이터를 전송하기 위한 객체이며 불변일 수 도 있다. VO 는 값에 관한 객체이며 일반적으로 불변이여야 한다. DTO : Data Transfer Object (데이터. 전송. 객체) 처음 단어를 보았을때 엥 이게 뭐야 라는 생각을 했었다. DTO 를 DDD 의 Layerd 아키택처에서 다음 두가지 경우로 이용 할 수 있다. 1. API Layer 즉 controller 단에서 사용자와 데이터를 특정 형식으로 주고 받는 경우 . 2..

DDD ,, DDD ,, DDD 벡엔드 엔지니어의 길을 걷고자 공부한 지난 1년간 정말 많은 블로그에서 보고 들은 단어 이지만 , DDD 가 뭐다 ! 라고 명확하게 이야기를 못한 자신을 보았다. 그러한 이유는 명확한 정의, 이론들을 알지 못한 상황에서 기능을 급급하게 만들었던, 모래성을 쌓는 것 과 같은 일을 하고 있었기 때문이다. 이글을 통하여 나와 같이 DDD에 대하여 가볍게 넘어가거나 추상적으로만 개념이 있던 사람들에게 도움이 되고자 아직 부족하지만 나름의 경험과 공부했던 내용의 일부를 적어본다. DDD 정의 : DDD 는 도메인의 깊은 이해(process and domain rule)를 바탕으로 만들어진 도메인 모델을 중심으로 소프트웨어를 개발 및 설계하는 접근 법이다. DDD 이전에 MDD 라는..

- 이 글은 책 오브젝트 리뷰를 위한 메모 글이며, 공부 목적을 위한 노트 입니다. 객체지향 설계 두 가지 방식 상태 중심 : 구현이 불안정하기 때문에 객체의 상태가 인터페이스에 스며드는 변경에 취약한 코드가 생길 수 있다. 예시 ) 필요한 기능을 만들기 위하여 데이터를 우선적으로 생각하여 클라스를 만든후 접근 제어자를 넣어준후 중앙에서 통재하는 클라스에서 모든 객체의 상태를 호출하여 원하는 결과를 만드는 방식. 책에서는 데이터를 가지는 구현채들이 get ,set 이외의 로직이 없다. 작년 겨울에 짰던 코드: MVC 패턴을 생각 했지만 내부의 BL 이 없다. public class Player { private Exception exception; private List playerNumbers; pub..

수정 : 23년 4월 8일 "객체지향"이란 공통된 로직 ,공통된 데이터를 하나로 묶어서 하나로 관리를 하는 것 이다." 라는 답변은 22년 9월 , 객체지향의 사실과 오해 및 오브젝트 를 읽기전, 우아한 테크 코스 프리코스 참여 전에 생각한 답변이다. OOP : 객체 지향 프로그래밍 이다. 객체라는 말이 오해를 만든다고 포* 선생님은 "개체" 라고 부르신다. 공통된 로직 ,공통된 데이터를 하나로 묶어서 하나로 관리를 하는 것 은 객체지향이 아니라 캡슐화 이다. 객체지향 프로그래밍을 한다라는 것은 , 객체들이 메시지를 통하여 외부의 요청에 대하여 객체간 서로 상호작용을 하여 원하는 목적을 이루게 하는 프로그래밍을 하는 관점을 가지는 프로그래밍을 하자라는 페러다임이라고 이해를 하자. 왜 관점인가 ? 컴퓨터 ..

오브젝트 챕터 3의 내용은 책 객체지향의 사실과 오해 내내 했던 이야기이다. 협력(collaboration) ,책임(responsibility),역할(Role) 이라는 단어를 안다면 하단의 Solid 원칙을 다시한번 정리한 부분만 보고 넘어가도 충분하다. Point RDD : Responsibility Driven design 하자 , 상태보단 행위 이며 메시지가 객체를 선택하자 추상 클라스와 인터페이스 잘쓰자 협력 (collaboration) : 객체들끼리 어떠한 기능을 수행하기 위하여 하는 상호작용 책임(responsibility) : 협력에 참여하기 위해 객체가 수행하는 행동 . 역할(Role) : 어떤 특정한 협력 안에서 수행하는 책임의 집합. ~ DIP 한종류의 객체만 협력에 참여를 하는 상황이..

- 이 글은 객체지향의 사실과 오해 리뷰를 위한 메모 글이며, 공부 목적을 위한 노트 입니다. 글은 4월 초에 완성합니다. chpt 5 책임과 메시지 chpt 5 point : 메시지가 인터페이스를 결정한다. 메시지를 중심으로 생각을 하자. 인터페이스를 통해서만 다른 객체의 메시지를 보내고 , 메시지를 통해서만 다른 객체의 정보를 받을 수 있다. ISP 예시 : 인터페이스를 나누는 케이스 King. → message(증언하라) → Alice King. → message(증언하라= message name ) → Alice 자신의 의지에 따라 증언 할 수 있는자유 왕의 증언하라 라는 메시지 vs 목격했던 장면을 떠올려라 메시지 class A a = new A() ; → a.speakInCoart() →a.s..

- 이 글은 객체지향의 사실과 오해 리뷰를 위한 메모 글이며, 공부 목적을 위한 노트 입니다. 글은 4월 초에 완성합니다. chpt 3 타입과 추상 리스코프 치환 원칙을 먼저 설명한다. “서브 타입은 언제나 자신의 기반 타입(base type)으로 교체할 수 있어야 한다." 로버트 C. 마틴 조용호 님의 블로그 주소이다 : http://aeternum.egloos.com/ 토비님의 유투브에 나온 인터뷰에서 가져왔다. : https://www.youtube.com/watch?v=8OclN9kZTE4 책은 나오는 것 까지 7년이 걸렷다고 한다, 추상화를 통해 복잡성을 극복한다. 복잡한 런던 지하철의 초기 지도는 실측을 기반으로 사용자에게 정보를 제공하였지만, 복잡했다. 오늘날의 지하철은 역간의 거리와 상관 ..