2012-10-02 4 views
2

첫 번째 거래 시스템을 설계하려고하고 있는데, 모든 FIX 개념이 포함 된 올바른 Order 오브젝트를 설계하는 데 어려움을 겪고 있습니다. 숙련 된 사람들이 몇 가지 아이디어를 내놓을 수 있는지 궁금합니다.거래 시스템을위한 주문 오브젝트 설계

간단한 Order 클래스를 만들었습니다. 그러나 NewOrderSingle (FIX)이 생성되면 ClOrdId이 필요합니다. 그런 다음이 주문을 취소하면 새로운 ClOrdId (취소 할 때마다 FIX 메시지가 생성됨)이 필요하고 올바른 OrigClOrdId을 설정해야합니다. 따라서 나는 OrigClOrdIds을 추적해야합니다.

또한 시스템을 변경하지 않고 ClOrdId과 다른이 주문을 식별하기 위해 내 시스템 내부의 고유 ID를 유지해야한다고 생각합니다.

내 FIX 메시지와 관련된 다양한 ID 개념을 유지하면서이 주문 개체를 디자인하는 멋진 개체 지향적 인 방법은 없습니다.

사람들은 어떻게 이것을 현실 세계에서 디자인합니까? 어떤 제안? 감사.

+0

(http://www.quickfixj.org/) QuickfixJ는 오픈 소스 라이브러리입니다. 이를 확인하고 구현 세부 사항을 차트로 표시 할 수 있습니다. – DumbCoder

답변

1

이 클래스 다이어그램은 어떻습니까?

Order class diagram

취소 방법은 요청을 보내기 취소하는 데 사용할 수있는 새로운 SubOrder 구성한다. 다른 하위 주문 유형에 대해 더 많은 생성자 메서드를 추가 할 수 있습니다. 취소 주문이 매우 구체적이라면 주문 유형별로 하나의 클래스를 만들 수 있습니다. 공통점이 있다면 공통 클래스 인 AbstractOrder을 확장 할 수 있습니다. 뭐 그런 :

Class diagram with generalization

+0

감사합니다. 퀴즈 .. 어떤 UML을 사용 했습니까? – endless

+0

@ user1364959 [yEd] (http://www.yworks.com/en/products_yed_about.html) 정확히 UML 도구는 아니지만 무료입니다. –

1

나는 당신이 설명 정확히 할 몇 가지 시스템의 설계에 참여하고있다. 실제로 클래스 계층 구조를 설계하는 것보다 복잡합니다. 유의 사항 :

거래소 및/또는 자산 클래스에 따라 주문의 "고유 ID"는 실제로 태그의 조합 일 수 있습니다. 예를 들어 뉴욕 증권 거래소 (NYSE)의 "Classic"거래시 유일한 ID는 실제로 115 (OnBehalfOfCompID) + Tag 11 태그로 구성된 복합 ID입니다. 다른 장소의 경우 Tag 109 + Tag 11 또는 Tag 76 + Tag 11이 될 수 있습니다.

또한 별개의 장소로 보낸 ID가 동일 할 수 있다는 사실을 설명하기 위해 고유 ID에 데이터를 추가해야 할 수도 있습니다. 예를 들어 일부 장소의 경우 ClOrdID 값으로 Integer이 필요합니다. 이 경우 '고유 ID'의 내부 표현은 소금과 ID 데이터 (예 : DARKCROSS-1)가 있어야하며 (가상의) 장소는 'DARKCROSS'이고 1은 태그 11 값입니다.

여러 장소에서 주문의 고유 ID를 해결하는 비슷한 전략이있는 경우 상속을 통해 ID 팩토리로 논리를 추출 할 수 있습니다.

따라서 추상화는 AbstractOrder으로 시작될 수 있지만 NyseOrder, NasdaqOrder 등이 있어야 할 수 있습니다.

(내가 본 일부 구현에는 GenericFixOrder 클래스가 있거나 일부 클래스가 있습니다. 실제로는 각 장소마다 다른 동작이 약간 있습니다.)

또 다른 주제는 일반적으로 모든 시간에 고유 한 ID (즉, ID에 날짜가 있어야 함)가 있어야하며 여러 번 다시 시작하기 위해 애플리케이션에서 존속해야하는 Good Til Cancel 및 Good Til Date 주문입니다. 따라서 귀하의 ID 공장은 이러한 명령을 고려해야합니다.

ID의 관계에 대해서는 실제로는 매우 간단합니다. Order 개 개체의 고유 주문 ID가 Map입니다. 취소/바꾸기 또는 취소를 나타내는 클래스는 부모 주문을 참조합니다 (위에서 설명한 "고유 ID"필드와 동일하게 해석되는 "부모 주문 ID"필드를 통해).

원래 ("루트") 신규 주문에 대한 직접적인 참조가 필요하지 않습니다. 실제로 취소/대체가 수락 된 경우 주문을 보유한 Map에서 제거하는 것이 유용 할 수 있습니다. 취소가 수락되면 주문과 주문이 모두 완료되어 Map에서 주문을 완전히 삭제할 수 있습니다.

위의 내용은 일반적인 스케치입니다. 메모리에서 주문을 제거하는 것은 조숙 한 최적화로 간주 될 수 있습니다. 거래량이 적 으면 하루 종일 모든 거래 메시지를 메모리에 보관할 수 있습니다.