공부하고 있습니다 어니언 아키텍처과 제가 요점을 가지고 있습니다.어니언 아키텍처, 지속성 및 알림
어니언 아키텍처는 기술 인공물에서 도메인을 격리하는 데 목적이 있습니다. 따라서 DAL (데이터 액세스 계층)에서 도메인 계층 (BL)을 참조하도록하는 것이 지침입니다. 이렇게하면 개체를 저장소 아티팩트로 변형 할 수 있어야합니다. BL을 참조하면 내 도메인의 "스냅 샷"을 얻을 수 있지만 변경 추적 시스템을 사용하지 않으면 데이터 저장소에 항목을 삽입, 업데이트 또는 삭제할지 여부를 알 수있는 모든 연대순 이벤트를 풀어 올바르게 다시 수화 할 수 있습니다 그 이후의 모델.
오닉스 아키텍처에는 항상 변경 추적 시스템이나 이벤트 저장소 같은 것이 필요합니까? 다른 패턴이 빠졌습니까?
도메인 계층은 지속되어야 할 때를 알고 있습니까?
예를 들어, 내가 마침을 누르면 새 고객을 저장하는 신규/고객 업데이트 화면이있을 수 있습니다. 그 시점에서 나는 변화 추적을 걱정하지 않는다. 나는 갖고있는 모든 것을 저장하고 싶다. 내 DAL은 이미 데이터베이스에 같은 이름의 고객이 있는지 파악할 수 있습니다 (삽입 또는 업데이트 쿼리를 내 보내야하는 경우).
동일한 것은 이벤트 저장소에 적용됩니다. 도메인이 이벤트에 관심을 갖고 이벤트를 실행 취소 할 수있는 기술 구현이라면 이벤트 저장소.
도메인 계층은 항상 메모리가 가득한 라이브 변형 시스템으로 구성됩니다. 이 경우 스냅 샷조차도 없습니다.
어니언 아키텍처는 아티팩트의 분리를 설명합니다. 그들이 어떤 유물을 실제로 특정 요구 사항에 따라 달라집니다.
고마워, 좋은 설명이야, 알았어. –
응용 프로그램 계층이이를 담당한다고 가정합니다. 응용 프로그램 서비스는 도메인에 대한 호출을 조정하여 사용 사례를 구현합니다. 유스 케이스의 일부로 작성되거나 수정 된 도메인 엔티티는 이후의 지속성을 위해 하나의 형식 또는 다른 형식으로 메모리에 보유되어야합니다.
일반적인 작업 방법은 작업 단위 (인프라 계층에 구현되어 있음)에 작업 단위를 배치하는 것입니다. 도메인 엔티티에 대한 수정 사항을 추적합니다. 응용 프로그램 서비스가 비즈니스 트랜잭션을 끝내면 작업 단위는 엔티티 상태를 영구 저장소에 플러시 할 수있는 대상으로 변환합니다.
이벤트 저장소는 지속성 메커니즘 일뿐입니다. 양파 아키텍처는 외부의 종속성 순서를 정의하지만 사용해야 할 지속성에 대해서는 아무 것도 말하지 않습니다. 구현 세부 사항입니다. –
고마워 Alexey ... –