마이크로 서비스 및 Spring Boot을 사용하여 첫 번째 프로젝트를 계획하는 방법

이 블로그는 당신의 첫 번째 마이크로 서비스 프로젝트를 어떻게 준비하고 계획하는지에 관한 가능한 방법이다.그것은 실제 인코딩을 시작하기 전에 일반적으로 완성해야 하는 기본 절차를 묘사했다.
블로그 글을 계속 쓰려면 익숙해져야 한다.

  • REST API

  • Spring Boot 프레임워크와 간단한 프로젝트를 만드는 방법을 알고 있습니다.

  • microservices건물

  • 왜 계획을 세워야 합니까?
    내가 프리랜서 개발자일 때, 만약 내가 생각이 있다면, 나는 응용 프로그램에 대해 너무 많은 계획을 세우는 것을 개의치 않는다.나는 단지 최소한의 업무 목록을 만들 수 있을 뿐이다. 그러면 나는 하루 동안의 활동을 추적하고 인코딩을 시작할 수 있다.나한텐 이 정도면 충분해. 난 모든 일을 하는 사람이니까.
    네가 회사에서 일할 때, 그것은 완전히 다른 일이다.물론 이것은 회사에 달려 있지만, 대다수 상황에서, 당신은 더 이상 모든 일을 책임지는 사람이 아니다.통상적으로, 당신은 개발팀에 가입해서, 그들은 함께 프로젝트를 완성할 것이다.
    다음과 같은 이유로 계획이 중요합니다.
  • 사람마다 이 프로젝트에 대한 견해가 다르다
  • 모든 사람이 같은 프로젝트에 참여하고 기여할 것이다
  • 사람마다 다른 도구를 사용합니다
  • 만약 계획이 정확한 방식으로 정확하게 완성된다면, 모든 사람은 같은 페이지에 서서, 같은 방식으로 모든 프로젝트의 세부 사항을 이해하고, 같은 도구를 사용하여 개발할 수 있다.

    단계 1 - 마이크로 서비스 정의
    알다시피 마이크로 서비스는 하나의 구조 스타일로 응용 프로그램을 하나의 서비스로 구성한다.
    쉽게 말하면, 그것의 많은 작은 응용 프로그램들은 대형 응용 프로그램의 일부분이다.그것들은 부피가 작고 독립적이며 유지보수와 테스트가 쉬워 작은 단체가 단독으로 개발할 수 있다.
    단일 책임 원칙에 따라 마이크로 서비스를 정의하는 것은 좋은 방법이다.이것은 마이크로 서비스가 한 가지 임무만 맡아야 한다는 것을 의미한다.
    때때로 이러한 논리나 업무 임무를 정의하기 어려울 때가 있다. 어떤 상황에서는 명백히 알 수 있다. (예를 들어 인터넷 상점에는 틀림없이 사용자나 제품을 대상으로 하는 마이크로 서비스가 있을 것이다.)어쨌든 중요한 첫 번째 단계는 처음부터 그것들을 정의하는 것이다.
    모든 마이크로 서비스는 독립된 SpringBoot 프로젝트가 되어야 한다. 만약에 우리가 모든 마이크로 서비스에 서로 다른 기술을 사용하고 싶다면 이렇게 하는 것은 좋은 실천이다.
    예를 들어 하나는 자바로 PostgreSQL 데이터베이스를 작성하고 다른 하나는 Kotlin으로 MongoDB를 작성하고 사용할 수 있다.

    2단계 - 끝점 정의
    응용 프로그램에 어떤 마이크로 서비스가 포함될지 결정한 후에, 우리는 모든 마이크로 서비스에 대해 API의 단점을 정의할 수 있습니다.
    간단히 말해서 API 엔드포인트는 서비스의 URL입니다.API는 필요한 리소스를 얻을 수 있는 위치와 같습니다.
    하나의 API로 여러 끝점을 제공할 수 있습니다.모든 노드는 요청과 응답을 통해 조작한다. 클라이언트가 요청을 보내고, 노드가 응답을 보낸다.
    SpringBoot 응용 프로그램은 보통 localhost:8080에서 실행되기 때문에 만약에 저희 응용 프로그램이 옷가게라면 그 중의 API 단점은 다음과 같습니다.
    http://localhost:8080/clothes
    
    브라우저가 URL을 가져오면 GET 요청이 전송되고 옷가지 목록이 수신됩니다.
    따라서 두 번째 단계에서는 GET, POST, PUT 또는 DELETE와 같은 가장 중요한 HTTP 요청에 대해 응용 프로그램의 모든 끝점을 정의해야 합니다.

    3단계 - 클래스 정의
    아니오, 우리는 여전히 억지로 어떤 코드도 작성할 수 없습니다.) 나는 당신이 이 단계에서 코드를 작성하기를 얼마나 갈망하는지 알고 있지만, 인내심을 가지고 우리의 준비 작업은 이미 거의 완성되지 않았습니다.
    이 때, 우리는 응용 프로그램에서 사용할 모든 종류를 정의했다.우리는 현재 기본적으로 응용 프로그램의 구축 블록에 대해 전면적인 개술과 명확한 이해를 가지고 있다.
    우리는 또한 모든 종류가 어떤 속성과 방법을 가지고 있는지, 그리고 모든 속성이 어떤 유형을 가지고 있는지도 쓸 수 있다.

    4. 사용자 이야기 작성
    사용자 이야기는 Agile project management의 일부분이다.그것은 최종 사용자의 관점에서 소프트웨어 기능에 대한 비공식적인 설명이다.
    좋은, 간단한 사용자 이야기는 이 템플릿에 따라 작성된 문장이어야 한다.“As a [persona], I [want to], [so that].”예를 들어 "고객으로서 이름을 변경할 수 있도록 정보를 업데이트할 수 있기를 바랍니다."
    우리가 우리의 임무를 구체적인 사용자 이야기로 분해하고 이를 적절하게 묘사할 때, 이것은 이 기능을 실현할 개발자라면 누구나 무엇을 해야 하는지 확실히 알게 된다는 것을 의미한다.
    사용자 이야기에 대한 더 많은 정보를 얻으려면 여기에 좋은 글이 있습니다-User Stories with Examples and Template

    5. 와이어프레임 준비
    우리가 응용 프로그램 논리의 모든 상술한 준비를 마친 후에, 우리는 그것의 시각적 외관을 고려할 수 있다.응용 프로그램이 페이지에 있는 모습을 직관적으로 볼 수 있기 때문에 이 단계는 매우 중요하다.
    온라인 또는 로컬 그리기/와이어프레임(예: Sketch 또는 Figma)에 사용할 수 있는 수백 가지 도구와 웹 사이트가 있습니다.다른 개발자와 실시간으로 협업하여 초도를 그릴 수 있는 좋은 도구도 있다-https://excalidraw.com
    와이어프레임은 다음을 이해하고 분명하게 하는 데 도움이 됩니다.
    당신의 신청은 몇 페이지입니까
  • 데스크탑 및 모바일 뷰의 전체적인 레이아웃과 레이아웃이 무엇인지
  • 머리글과 꼬리글의 모양과 어떤 페이지에서 중복될지
  • 팝업 창의 모양
  • 모든 페이지의 테두리를 완성한 후에 우리는 우리가 구축할 응용 프로그램에 대해 견고한 이해와 견해를 가져야 한다.이제 실제 인코딩을 시작할 수 있습니다!:)

    좋은 웹페이지 즐겨찾기