"start:dev": "nest build --webpack --webpackPath webpack-hmr.config.js --watch", 스크립트를 사용하여 실행했을 때 콘솔에 찍히는 에러입니다.   // app.module.tsimport { MiddlewareConsumer, Module, NestModule } from '@nestjs/common';import { ConfigModule, ConfigService } from '@nestjs/config';import { AppController } from './app.controller';import { AppService } from './app.service';import { LoggerMiddleware } from './middlewares/logger.middleware';import { UsersModule } from './users/users.module';import { WorkspacesModule } from './workspaces/workspaces.module';import { ChannelsModule } from './channels/channels.module';import { DmsModule } from './dms/dms.module';import { TypeOrmModule } from '@nestjs/typeorm';@Module({ imports: [ ConfigModule.forRoot({ isGlobal: true }), TypeOrmModule.forRoot({ type: 'mysql', host: 'localhost', port: 3306, username: process.env.DB_USERNAME, password: process.env.DB_PASSWORD, database: process.env.DB_DATABASE, autoLoadEntities: true, keepConnectionAlive: true, migrations: [__dirname + '/migrations/*.ts'], charset: 'utf8mb4', synchronize: true, logging: true, }), UsersModule, WorkspacesModule, ChannelsModule, DmsModule, ], controllers: [AppController], providers: [AppService, ConfigService],})export class AppModule implements NestModule { configure(consumer: MiddlewareConsumer): any { consumer.apply(LoggerMiddleware).forRoutes('*'); }} TypeOrm 모듈 관련 부분입니다.   mysql에 스키마는 직접 만들어야 한다고 하셔서 만들은 화면입니다.     typeORM 0.3.0 을 사용을 하고 있으며,  ormconfig.ts 파일 대신 dataSource.ts 파일로 바꾼 상태지만, app.module.ts를 확인해보면 dataSource.ts 파일을 사용하지 않고 직접 설정 정보를 넣어준 상태입니다.에러코드 관련해서 검색을 해보니 webpack 문제라는 글을 보긴 했는데, 정말 webpack 때문에 발생한 오류인지, 그렇다면 어떻게 해결해야하는지 모르겠습니다.  

안녕하세요. 이번 강의 내용에서 추가적인 요구사항을 적용해보는 중, 설계상 궁금증이 생겨 질문하게 되었습니다. jpashop에서는 환불제도 악용 회원의 주문을 일정 기간동안 금지할 수 있다는 요구사항을 추가했습니다. 이 변경된 요구사항을 위해, MemberStatus라는 VO를 Member 클래스에 추가했습니다.  결과적으로, Order 클래스를 생성함에 있어서 MemberStatus의 로직(다른 애그리거트의 Value Object)을 필요로 합니다. 이 때, 선택할 수 있는 생성 방식이 여러개가 떠올라서, 이들의 선택 기준에 대한 조언을 듣고 싶습니다. 첫번째 방식. 정적 팩토리 메서드의 매개변수로 추가 첫번째 방식은 생성시 필요한 정보를 가진 객체(MemberStatus)들을, 정적 팩토리 메서드의 매개변수로 전달합니다. 선택 기준은  객체(Order)를 생성함에 있어서, 특정 객체(MemberStatus)가 필요함을 명시적으로 알릴 수 있습니다. 생성로직을 해당 클래스가 전적으로 제어하는 것이 생성 로직을 한 곳에 더 응집시킬 수 있습니다. 이 두가지를 고려했습니다. 이 방식에서는 회원 차단에 따른동작 분기는 정적 팩토리 메서드 내에서 이루어집니다. 다만, Order를 생성하는데 있어서 MemberStatus 이외에도 협력해야 할 애그리거트들이 많이 존재하는 경우 Order 클래스가 너무 많은 의존성을 가지게 될 수 있다는 점이 우려됩니다. 두번째 방식. 생성을 위한 정보/로직을 가지고 있는 클래스가 생성을 담당 선택 기준은  Member가 Order를 생성하기 위한 로직(회원 차단 여부)을 제공합니다. 위 내용을 고려했습니다. 이 방식에서는 검증 통과 여부에 따른 동작 분기는 Member의 메서드 내에서 이루어집니다. 다만, 이 방식은 Member —> Order로의 불필요한 의존성을 만들어낼 수 있다고 우려했습니다 특히, 생성에 대한 책임을 맡는다는 것은 내부에 어떤 데이터를 가지고 있는지 전부 알아야 한다는 점에서 생각보다 과도한 의존성을 부여하고 있는 것 같습니다. 또한 협력해야 할 애그리거트가 많아질 수록, Member가 생성과 관련된 다른 클래스들에 대한 많은 의존성을 감당해야 한다는 점이 우려됩니다. 세번째 방식. 애그리거트를 생성하는 Domain Service를 만든다. 선택기준은 많은 의존성을 가져야 하는 생성 로직을 서비스에 담음으로서, 엔티티가 불필요한 의존성을 가지는 것을 방지합니다. 위 내용을 고려했습니다. 다만, 조금만 복잡해져도 도메인 서비스를 사용하고자 하는 유혹이 생겨서, 자칫하면 다른 로직들도 Domain Service로 구현해, Entity 자체의 응집성이 작아지는게 아닌가 우려스럽습니다. 질문 내용 정리 1. 각 생성 방식을 선택함에 있어서 미흡한 선택 기준에 대해서 조언 해주 실 수 있나요? 2. 또 첫번째, 두번째 방식이 우려하는 사항들은 현재의 사례에서는 잘 드러나지 않는 '잠정적인' 우려사항들인데, 실제로 이 우려사항들이 나타나기 전까지는 가장 간단한 구현(첫번째 혹은 두번째)을 그대로 사용해도 될까요?