빈혈이나 부영역 모델이 있습니까?

부영역 모델은 영역 구동 디자인의 기술 부분이다.그것은 많은 구축 블록으로 구성되어 있지만, 나는 다른 모델 보기를 보여 주고 싶다.이것은 이 화제에 관한 많은 시리즈 문장 중의 하나다.

심층 계통

데이터 모델은 어느 정도에 응용 프로그램 체계 구조를 결정한다.간단한 CRUD 응용 프로그램의 경우 일반적으로 솔리드를 가져오고 밀어넣기라는 구어 가정을 가정할 수 있습니다.이 경우 데이터 모델, 데이터를 관리하는 서비스 계층 및 API 인터페이스로 충분합니다.
불행하게도, 이른바 깊이 있는 시스템, 즉 사용자 인터페이스에서 지정할 수 없는 시스템의 경우, UI에서 보듯이 시스템에서 실행된 동작을 반영하지 않습니다.업무 논리, 통합, 스케줄러, 그리고 많은 백엔드 조작이 아래에서 실행된다.이런 상황에서 대부분의 강좌에 등장하는 원시적인 방법을 사용하면 결국 스파게티 코드를 얻을 수 있다. 이것은 개발자의 슬픔이기 때문에 지속가능하지 못한 시스템이다.어떻게 의식적으로, 현명하게 그것을 대합니까?
빈혈 데이터 모델은 2003년 Martin Fowler에서 역모드로 정의되었습니다.그는 이것이 대상 프로그래밍과 일치하지 않고 과정 프로그래밍과 일치한다고 강조했다.

“The anemic domain model is really just a procedural style design…”

그런데 이게 도대체 무슨 빈혈이야...?

원본 모델

일반적으로 범용 모델의 초대형 실체는 활력이 부족한 모델로 불리는데 그 중에서 부주의한 Getter와setter가 가득하다. 이것은 업무를 반영하지 않고 데이터 구조를 반영하는 SQL에서 나온 표이다.문제는 반드시 관계 데이터베이스 응용 프로그램의 문제가 아니다.유행하는(그리고 얼마나 아름다운) NoSQL 데이터베이스 세계에서 이러한 실체는 거의 SQL 실체와 같아 보일 수 있다. 단지 인용이 아니라 끼워 넣는 모델을 볼 수 있을 뿐이다. 이것은 구약전서(golden class)와 크기가 같은 JSON 데이터 라이브러리를 생성할 것이다.
따라서 더 나쁘거나 더 좋은 데이터베이스가 없으면 주어진 상황에서 더 나쁘거나 더 나쁘게 사용된다는 것을 명심해야 한다.

public class Order {
    private Long orderId;
    private LocalDate orderDate;
    private LocalDate orderShippedDate;
    private String orderStatusCode;
    private int orderTotal;
    private Long customerId;
    private String shipToName;
    private Long shipToAddressId;
    private String shipToPhoneNumber;
    private Long shippingOptionId;
    private Long paymentOptionId;
    // getters and setters
}

이것은 응용 프로그램에서 사용하는 실제 코드의 한 예이다. 여기에 무슨 좋은 것이 있습니까?아니...
우리 기초부터 시작합시다.

If you are calling two setters in a row, you are missing a concept (Oliver Gierke)

프로그래밍 언어를 배울 때, 우리는 항상 봉인에 대해 이야기한다.우리는 데이터의 변경을 방지하기를 바란다.그러나 클래스 행위를 정의하지 않으면 상태를 어떻게 변경하시겠습니까?나는 당연히 잊었지, 우리는 두 명의 세터가 있다는 것을.왜 우리는 그것들이 있는가. 왜냐하면 우리는 공공 필드를 사용할 수 있기 때문이다. 이것은 다를 것이 없다. 이 두 가지 상황에서 모두 봉인하지 않았다. (클래스는 어떤 일을 할 수 있고 모든 사람이 클래스를 조종할 수 있다(이곳에는 봉인하거나 유한한 책임이 없다).
또 다른 문제.과도하게 범화되어 특정 영역 모델이 운행되는 배경이 없다.
상업 운영 방식을 이해하다.

이전 모델에서 주문서의 상하문은 혼합된 것으로 서로 다른 상태와 수십 개의 의존항을 가지고 있을 수 있다.사실 이 질서는 위의 체인처럼 변화하고 있다.우리는 상품을 주문할 때, 우리는 반드시 재고에 대해 초기 예약을 하고, 주어진 요구를 처리해야 하며, 그것이 실현될 때, 우리는 주문을 토론할 수 있다고 가정할 수 있다.주문이 완료되면 배송을 위해 포장하여 창고로 보냅니다. 또한 주문서에 대한 청구서를 작성하여 고객에게 보냅니다.모든 상하문은 자신의 필드, 조건, 논리와 봉인을 가지고 있다.
관심 기능을 통해 실체 서비스를 피하다
그렇다면 빈혈 모델의 역할은 무엇일까?

유지보수/개발 응용 프로그램의 문제점, 모호한 논리가 분야를 넘어 많은 의존관계-대결합

이른바 골드 레벨

에서 실행되면서 성능이 떨어졌다

복잡한 논리로 보통 많은 부울이나 매거진에서 운행한다

과도한 범용 모델의 주정역 운행의 상하문

이 종류는 모든 일을 할 수 있고 모든 사람이 이 종류를 조종할 수 있다

Liskov 규칙 깨기 - 사용.get().get()

집합 의도 알 수 없음:

이곳에서 어떤 상업 활동이 일어나고 있습니까? 우리는 아직 그것을 명명하지 않았기 때문에 잘 모르겠습니다.
내가 언제 이런 방법을 쓰고 싶었을까?나 뭐 헷갈린 거 없어?
두 달 후, 나는 이곳에서 무슨 일이 일어났는지 알 수 있습니까?
제가 더 많은 값을 설정하는 걸 잊어버리면요?
다른 사람들이 실체를 관리하고 그녀에게 어떻게 생활하고 무엇을 하는지 알려주는 것은 보통 슈퍼 서비스이다. My Fancy Execution Manager 서비스. 이런 무능함은:)

풍부한 모형

이 방법은 그 의도를 표현한다

상업 언어 진입 코드

실체는 변할 수 없고 집합이 없고 무엇이든 할 수 있는 공공방법

대상의 방법은 우리가 무엇을 잊었는지 걱정하지 않아도 되풀이해서 사용할 수 있다

실체는 자신을 관리하는데 오직 그것만이 상태를 바꾸고 상태를 검증하며 반응할 수 있다. 그것은 성숙하고 독립적이다

영역 구동의 디자인 이념은 풍부한 영역의 개념에 완전히 부합된다.다음은 DDD 기반 프로젝트에 대해 설명합니다.
도메인 기반 설계를 사용한 라이브러리 프로젝트 - GitHub

예를 들어 ddd를 설명하다 / 도서관.

전면적인 분야 구동 설계 예시로 문제 공간 전략 분석과 각종 전술 모델을 포함한다.

리치 모델의 어셈블리(예:

고접착력

가치 대상

유계상하문

이벤트

육각형 건축

사용 예제

물론 실용적인 방법도 있지

다음 이야기에 등장한다.빈혈 모형을 돌기만 하면 너는 업무의 질을 현저하게 향상시킬 수 있다.분야 구동의 디자인에 주목하다.