안녕하세요, 토비님. 도메인 모델의 정의 범위에 대해 토비님의 생각이 궁금하여 질문드립니다. 현재 저는 MSA 환경에서 여러 시스템이 나뉘어 있는 구조에서 일하고 있습니다. 보통 팀에서는 “우리가 생성·저장하는 데이터 구조” 를 도메인 모델로 이해하는 경우가 많은데요, 저는 도메인 모델의 범위가 그보다 더 넓다고 생각하고 있습니다. 예를 들어, 주문시스템이 있다고 할 때, 주문시스템은 주문데이터를 생성/관리하는 책임을 지겠지만 이를 위해서 여러 시스템(상품, 프로모션, 결제 등)에서 데이터를 조회해 조합하여 업무 규칙을 수행하는 책임을 가질 수 있습니다 . 이 경우, 다른 시스템이 생성·관리하는 개념이라 하더라도, 주문시스템 내부에서의 목적과 규칙에 따라 주문에 맞는 방식으로 추상화된 모델을 정의하는 것 이 바로 도메인 모델이라고 생각하는데요. 즉, 외부 개념이라도 주문시스템의 책임 하에 있는 로직과 규칙이 있다면, 그것은 주문의 도메인이다 라는 관점입니다. 이와 같은 관점에 대해 토비님은 어떻게 생각하시는지, 도메인 모델 정의의 기준에 대해 의견을 듣고 싶습니다. 감사합니다.
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] localhost:8080/hello를 가면 이렇게 뜹니다ㅜㅜ
제가 객체지향 처음배울때 이해하기 쉬웠던 비유를 적어놓을게요 클래스는 설계도와 같습니다 안에 어떤 데이터와 기능이 들어갈지 정의만 합니다 건축에서 건축 설계도와 같습니다 어떤 자재와 공간이 있을지 정의만 합니다 ( 설계도를 그려놨다 해서 실제 건축물도 생기는건 아닙니다 ) 객체는 건축물과 같습니다 설계도를 바탕으로 실제로 구현된 대상입니다. (네, 객체는 클래스를 기반으로 만듭니다) 즉, 객체는 클래스를 기반으로 구현된 구체화된 실체입니다. 그래서 클래스 정의 -> 객체 생성 이 절차를 따릅니다. 한 설계도를 기반으로 여러 건축물을 만들수 있듯이 클래스 하나를 설계하면 여러 객체를 만들수 있습니다 클래스 = 설계도 객체 = 구체화된 실체 감사합니다.
3분 43초경, 책임을 나누는 부류에서 "누가 해당 메서드의 변경을 유발하는 사용자인가"가 기준이 된다고 하셨는데, 메서드의 변경을 유발한다는 게 해당 메서드를 누가 호출하느냐? 어떤 사용자가 이 메서드를 사용하냐? 이렇게 이해하면 되나요? 메서의 변경을 유발한다는 의미가 해당 메서드를 이용한다는 의미인지? 정확히 메서드의 변경을 유발한다는 점이 무슨말인지 모르겠습니다.
임시영상 시청을 했습니다. 일단 확실한 답을 달라는건 아니고 제가 영상을 제대로 이해한게 맞는지 여쭤봅니다. 타겟값 0을 그냥 냅둔케이스가 삭제한케이스보다 조금더 안정적인걸까요? 영상에선 삭제한케이스의 오차값이 어마어마하게 커지는데 아무것도 안한케이스는 소폭의 차이밖에없는것 같아서요
안녕하세요 선생님 강의 잘 듣고 있는 학생입니다. 요즘 저의 custom dataset으로 여러 object detection 모델을 돌려보고 있는데 시작은 보통 pytorch의 pt모델로 학습을 시작을 하는데 제가 임베디드 시스템에서 돌려보고 싶어서 추론을 하고 싶어 PyTorch -> onnx -> tensorflow -> tflite 변환 구조를 따라가 최종 모델을 tflite로 구성하려고 하는데 양자화를 하지 않았는데도 tflite(float32) 성능이 아예 떨어져 pytorch에서는 잘 detect하던 모델이 아예 검출을 하지 못하는 상황이 발생하는데 혹시 이러한 상황이 아무래도 모델을 tflite로 축소하다 보니 자연스러운 상황인건지 이러한 상황을 극복하려면 데이터를 더 수집해서 성능을 높여야하는지 방법에 대해서도 좀 여쭙고 싶습니다. 감사합니다~
강의 잘 듣도 있습니다. 문의드릴내용은 PRD문서 의 API 문서 오퍼레이션명세 [행사정보조회] 의 경우, 한국관광공사 매뉴얼을 복붙하셨다고 했는데, 저는 아래처럼 되지 선생님처럼 안되거든요. 오퍼레이션 번호 6 오퍼레이션 유형 조회 (목록) 오퍼레이션명(국문) 행사정보조회 오퍼레이션 설명 행사/공연/축제 정보를 날짜로 조회하는 기능입니다. 콘텐츠 타입이 “행사/공연/축제”인 경우만 유효합니다. 선생님이 아래와 같이 하신 방법은 어떻게 가능한가요? 만드신 건가요? 아니면 뭔가 툴이 있을까여~ | 오퍼레이션 번호 | | 6 | 오퍼레이션 유형 | 조회 (목록) | | --- | --- | --- | --- | --- | | 오퍼레이션명(국문) | | 행사정보조회 | | | | 오퍼레이션 설명 | | 행사/공연/축제정보를날짜로조회하는기능입니다.
@Test void find() { Member member = memberRegister.register(MemberFixture.createMemberRegisterRequest()); entityManager.flush(); entityManager.clear(); Member found = memberFinder.find(member.getId()); assertThat(member.getId()).isEqualTo(found.getId()); } 현재 코드에서 위와 같이 테스트에서 회원 저장을 위해 memberRegister.register를 호출하고 있습니다. 그런데 memberRegister.register에는 단순히 회원을 저장하는 것 외에도 이메일 전송 같은 부가적인 로직이 포함되어 있습니다. 이러한 부가적인 로직때문에 테스트 속도가 느려진다던가, 테스트가 실패하는 원인이 될 수 있다고 생각이 들었습니다. 이처럼 테스트 준비에 필요하지 않은 부가 로직까지 수행되는 상황에서, memberRegister.register를 테스트 준비 용도로 사용하는 것이 적절한지 토비님의 생각이 궁금합니다.
도메인 모델에서의 검증과 애플리케이션 레벨 검증의 경계에 대해 질문드립니다. 현재 도메인 모델에서는 이메일 형식이 올바른지, 닉네임이나 비밀번호가 null이 아닌지 같은 최소한의 조건만 검증하고 있습니다. 반면, 비밀번호가 8자 이상인지, 닉네임이 5자 이상인지 같은 검증은 애플리케이션 레이어에서 처리하고 있습니다. 그런데 닉네임이 5자 이상이어야 한다 같은 규칙도 도메인 규칙으로 볼 수 있지 않을까 라고 생각이 들어 해당 검증 역시 도메인 모델에서 처리하는게 맞지 않나 라는 생각이 드는데, 도메인 모델에서의 검증과 애플리케이션 레벨 검증의 경계는 어디까지 두는 게 좋은지 토비님 의견이 궁금합니다. 말씀하신것을 토대로 예측해 봤을때 형식이나 정책적 요구사항(변경 가능성이 있는 규칙)은 애플리케이션 레이어에서, 도메인의 본질적 불변 조건은 도메인에서 검증하는 걸까요?
안녕하세요, 먼저 강의 잘 들었습니다. AUTOSAR에 대한 기초 개념을 잘 정리 할 수 있었던 시간이었습니다. ASW 개발 시 AUTOSAR 도구를 이용하여 component, port 등을 정의하고 그에 따라 Code generation 후, 내부 로직을 채워나가는 방식으로 진행이 된다 하셨는데, 어쨌든 코드 레벨에서는, RTE를 통한 데이터 교환이나 Server/Client 함수 호출이 아닌, 직접적인 전역 변수의 접근이나 타 컴포넌트의 함수 직접 호출을 구현 할 수도 있다는 생각이 들었습니다. 이에 대해 AUTOSAR 규칙에 맞지 않는 설계 방법이라는 설명을 해 주셨으나, 결과적으로 해당 내용이 빌드가 가능하고 참조 구조가 명백하다면 실행이 가능한 SW가 만들어질 수 있어 보이는데요. 이러한 AUTOSAR compliance 하지 않은 구현이 이루어진다면 어떤 일이 발생하나요?? 혹은, OEM 등에서 관련한 제약을 따로 명시하지 않을 경우, 이러한 구현이 결과적으로 문제가 될 가능성은 없을까요?
