서비스 지향 대 객체 지향-공존 할 수 있습니까?

StackOverflow https://stackoverflow.com/questions/442815

  •  22-07-2019
  •  | 
  •  

문제

많은 관심이있었습니다 서비스 지향 아키텍처 (SOA) 최근 회사에서. 우리가 그것을 어떻게 사용할 수 있는지 보려고 할 때마다 나는 항상 정신적 블록에 대항하여 달려갑니다. Crudely :

  • 객체 지향은 다음과 같이 말합니다. "데이터 (비즈니스 프로세스)를 함께 조작하는 데이터와 방법을 유지하십시오";

  • 서비스 지향은 "서비스에서 비즈니스 프로세스를 유지하고 데이터를 전달합니다"라고 말합니다.

SOA를 개발하려는 이전의 시도는 객체 지향 코드를 데이터 구조로 변환하고이를 조작하는 별도의 절차 (서비스)로 변환했습니다.

내 질문은 다음과 같습니다. SOA와 OO가 함께 일할 수 있도록 어떤 패턴, 아키텍처, 전략 등이 있습니까?

편집하다: "내부를위한 OO, 시스템 경계를위한 SOA"라는 대답은 훌륭하고 유용하지만 이것이 제가 얻은 것은 아닙니다.

당신이 있다고 가정 해 봅시다 Account 사업 운영이있는 개체 Merge 그것은 다른 계정과 결합합니다. 일반적인 OO 접근법은 다음과 같습니다.

Account mainAccount = database.loadAccount(mainId);
Account lesserAccount = database.loadAccount(lesserId);

mainAccount.mergeWith(lesserAccount);

mainAccount.save();
lesserAccount.delete();

내가 본 SOA 동등한 것은 다음과 같이 보인다.

Account mainAccount = accountService.loadAccount(mainId);
Account lesserAccount = accountService.loadAccount(lesserId);

accountService.merge(mainAccount, lesserAccount);
// save and delete handled by the service

OO의 경우 비즈니스 로직 (및 Activerecord 패턴 덕분에 엔터티 인식)이 Account 수업. SOA의 경우 Account 모든 비즈니스 규칙이 서비스에 묻혀 있기 때문에 물체는 실제로 구조 일뿐입니다.

풍부하고 기능적인 수업과 재사용 가능한 서비스를 동시에 가질 수 있습니까?

도움이 되었습니까?

해결책

나는 SOA가 외부 인터페이스 (일반적으로 회사 외부의 사람들에게는 말하면)에만 유용하다고 생각하며, 성능이 실제로 중요하지 않은 경우에만 메시지를 주문할 필요가 없습니다.

그것에 비추어, 나는 그들이 공존 할 수 있다고 생각합니다. OO 철학을 사용하여 응용 프로그램을 계속 작동시키고 통신하고 외부 인터페이스 (제 3 자에게)가 필요한 경우에만 SOA를 통해 노출하십시오 (이것은 필수는 아니지만 한 가지 방법입니다).

나는 정말로 SOA가 과도하게 사용되었거나 적어도 SOA가있는 건축물이 너무 자주 제안되고 있다고 생각합니다. 나는 내부적으로 SOA를 사용하는 큰 시스템에 대해 실제로 알지 못하며, 그들이 할 수있을 것입니다. 매시업이나 간단한 일기 예보 유형 요청을 수행하는 데 사용할 수있는 더 많은 것 같습니다.

다른 팁

내 의견은 SOA가 거시적 수준에서 유용 할 수 있지만 각 서비스는 아마도 여러 내부 구성 요소가 필요할 정도로 충분히 클 것입니다. 내부 구성 요소는 OO 아키텍처의 혜택을 누릴 수 있습니다.

SOA API는 외부 API이므로 내부 API보다 더 신중하게 정의되어야합니다. 이 레벨에서 전달 된 데이터 유형은 내부 논리가 없으면 가능한 한 간단해야합니다. 데이터 유형 (예 : 유효성 검사)에 속하는 논리가있는 경우 데이터 유형에서 로직을 실행하는 것이 바람직하게는 하나의 서비스가 있어야합니다.

SOA는 시스템이나 응용 프로그램간에 의사 소통하기위한 좋은 아키텍처입니다.

각 응용 프로그램은 처리 할 요청과 예상되는 응답으로 구성된 "서비스"인터페이스를 정의합니다.

여기서 핵심 요점은 잘 정의 된 인터페이스가있는 잘 정의 된 서비스입니다. SOA에 관한 한 서비스가 실제로 칭찬되는 방법은 관련이 없습니다.

따라서 최신 및 가장 큰 OO TequNique 또는 귀하에게 적합한 다른 방법을 제공하는 서비스를 무료로 구현할 수 있습니다. (나는 실제 인간이 화면에 데이터를 입력하는 실제 인간이 "서비스"가 이식되는 극단적 인 경우를 보았지만 여전히 모든 것이 여전히 교과서 소아였습니다!).

나는 이것이 객체 방향의 오해라고 생각합니다. Java에서도 방법은 일반적으로 사물 그러나 그들의 수업 (그리고이 "멤버십"조차 객체 방향에 필요하지 않지만 다른 주제입니다). 클래스는 유형에 대한 설명 일 뿐이므로 이것은 실제로 데이터가 아니라 프로그램의 일부입니다.

Soa와 Oo는 서로 모순되지 않습니다. 서비스는 데이터를 수락하고 내부적으로 객체로 구성하고 작업을 수행하며 최종적으로 원하는 형식으로 돌려줍니다.

제임스 고슬링이 코볼에서 SOA를 구현할 수 있다고 말하는 것을 들었습니다.

OOP의 기원에 대한 Alan Kay의 자신의 설명을 읽으면 유용한 것을 수행하기 위해 상호 작용하는 작은 컴퓨터를 설명합니다.

이 설명을 고려하십시오 :

X는 YS로 구성되어야합니다. 각 y는 단일 개념을 담당해야하며 인터페이스 측면에서 완전히 설명 할 수 있어야합니다. 하나의 Y는 다른 y에게 메시지 교환을 통해 무언가를하도록 요청할 수 있습니다 (지정된 인터페이스에 따라).

경우에 따라 x는 z에 의해 구현 될 수 있으며, 이는 인터페이스에 따라 관리됩니다. X는 다른 X의 Z에 직접 액세스 할 수 없습니다.

다음과 같은 대체가 가능하다고 생각합니다.

Term      Programing       Architecture
----    ---------------    ------------
  X         Program           System
  Y         Objects          Services
  Z      Data structure      Database
----    ---------------    ------------
result        OOP              SOA

주로 캡슐화, 정보 숨기기, 느슨한 커플 링 및 블랙 박스 인터페이스 측면에서 생각한다면 약간의 유사성이 있습니다. 다형성, 상속 등이 쇠약 해지면 아키텍처 대신 프로그래밍 / 구현을 생각하고 있습니다.

서비스가 상태를 기억하도록 허용한다면, 호출 시간이 느려질 수있는 큰 대상으로 간주 될 수 있습니다.

그들이 상태를 유지할 수 없다면, 그들은 당신이 말한대로 데이터에 대한 연산자입니다.

시스템을 너무 많은 서비스로 나누는 것 같습니다. 나누는 방법에 대한 상호 합의 된 기준을 작성 했습니까?

SOA를 채택합니다 ~ 아니다 평균 모든 물건을 버리십시오 그러나 시스템을 큰 재사용 가능한 덩어리로 나누는 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top