분할 및 명명 Microservices

Question

최근에 사이드 프로젝트를 시작했습니다. 그것은 조리법 (CRUD)을 저장하고 검색하고, 평가하고, 검색 할 수있는 기능을 갖춘 가상 조리법 책이었습니다. 이것은 새로운 것은 아니지만 데이터베이스, 단위 테스트, UI 등에 대해 더 자세히 알기 위해 데스크톱 응용 프로그램으로 구축하고 싶습니다. 이제 코어 도메인이 거의 완료되었고 (DDD 접근 방식을 사용함) CRUD 저장소의 대부분을 구현 했으므로 핵심 기능을 온라인으로 호스팅함으로써 좀 더 확장 가능하게 만들고 싶습니다. 그래서 여러 백엔드를 작성할 수 있습니다. 데스크톱 응용 프로그램, 웹 응용 프로그램, 웹 API 등).

서비스 지향 아키텍처 (또는 마이크로 서비스)는 저에게 좋은 접근 방법처럼 들립니다. 내가 직면 한 문제는 내 프로젝트의 어느 부분이 별도의 서비스에 속하고 어떻게 이름을 짓는 지 결정하는 것입니다.

프로젝트의 다음 부분을 가지고 :

• 핵심 도메인 (집계, 엔티티, 값 개체, 논리) ->자바
• 지속성 (DAO를, 저장소, 여러 데이터베이스 백엔드 구현) - >자바
• 검색 (검색을위한 지속성에 DB를 SQL 쿼리를 사용하는 검색 서비스) ->자바
• 데스크톱 응용 프로그램 ->JS (전자) 또는 자바 FX
• 웹 응용 프로그램 ->플라스크 또는 레일
• 웹 API (REST 사용하여 레시피를 검색, 평가, 관리) ->를?

내 초기 접근 방식은 하나의 하위 프로젝트로 핵심 도메인, 지속성, 검색 및 웹 API를 넣어 Heroku가 또는 비슷한에 그 전체 스택을 개최하는 것입니다. 그렇게하면 고객이 웹 인터페이스를 사용할 수 있습니다. 데스크톱과 웹 앱은 독자적으로 다른 프로젝트가 될 것입니다. Dektop 앱은 둘 다 Java로 작성된 경우 핵심 도메인을 공유 할 수 있습니다.

이 방법이 효과적인 방법입니까, 아니면 첫 번째 서비스를 더 작은 부분으로 나누어야합니까? 이 서비스의 이름은 무엇입니까?

Answer 1

GOTO 2015 컨퍼런스 (https://youtu.be/yPvef9R3k-M)에서 Eric Evans가 100 % 동의 한 후 귀하의 질문에 답변했습니다. 마이크로 서비스 범위는 하나 이상의 경계 된 컨텍스트 여야합니다. 지속성, REST/HTTP API 등을위한 지원 클래스를 포함합니다. 제가 알고 있듯이 마이크로 서비스는 격리, 확장 및 복원 측면을 추가하여 Bounded Context를 통한 배포 래퍼입니다. 작성한 바와 같이 바운드 컨텍스트를 정의하기 위해 전략적 디자인을 적용하지 않았습니다. 앱을 부품으로 뜯기 전에 점검 할 시간.