의견 1. Not-Always-Valid Domain Model

The fallacy of the always-valid entity

엔티티를 항상 유효하게 유지하려는 시도는 무의미합니다. 나쁜 일이 발생하도록 내버려둔 다음 유효성을 검사하세요.

엔티티의 속성에 대한 유효성 검사에 대한 비즈니스 규칙은 엔티티 클래스 외부에 있어야 합니다.

근거

• 유효성 검사 규칙은 상황에 따라 다르며 모든 사용 사례에 동일하게 적용될 수 없습니다.
• 유효성 검사 중에 반환되는 메시지는 프레젠테이션 계층의 책임이며 도메인 계층에 있어서는 안 됩니다.
• 기존 유효성 검사 규칙은 옛날 데이터에 적용되지 않을 수 있습니다.

의견 2. Alway-Valid Domain Model

Always-Valid Domain Model

불변성은 도메인 클래스 자체를 정의하는 규칙이기 때문에 도메인 클래스는 항상 불변성을 만족해야 한다. 대신 애플리케이션 수준에서 사용자 입력 유효성을 검사하여 사용자 출력 메시지를 애플리케이션에서 정할 수 있고, 도메인 계층에서의 불변성 위반을 막을 수 있다.

요약

• Domain classes should always guard themselves against becoming invalid.
• Invariants define the domain class: that class is what it is because of them.
• Input validation and domain invariants stem from the same business rules. The difference between the two is a matter of perspective:
  • Business rules manifest themselves as invariants in the domain model.
  • Business rules manifest themselves as input validation in application services.
• Invariant violation is an exceptional situation; use exceptions.
• Invalid input is not an exceptional situation; use a Result class.
• There’s no difference between "data validation" and "business rules validation". All validations, not matter how simple, are a result of business requirements.
• The validation context is part of the domain knowledge and should reside in the domain model:
  • The domain model should provide an API for the application layer to use this knowledge for input validation.
  • The domain model should use the same API for invariant checks.
• To remove text messages from the domain layer, use error codes instead of text and convert those code to text in the presentation layer.