소개하다.

최근에 나는 모교에서 열린 해커 대회에서 소규모 기술 강연을 할 기회가 있었다.그 목표는 소프트웨어 엔지니어에게 어떤 것들을 어떻게 구축하는지 가르치고 그들에게 현장에서 시범을 보여주는 것이다.나는 학생들에게 대표적인 화제를 선택하고 싶다. 나는 대부분의 엔지니어들이 무엇을 하고 있다고 생각하지만, 나도 경험이 좀 있다.전자상거래 분야에서 오랫동안 일한 후에, 나는 AWS를 사용하여 상점을 하나 실현하는 것이 이 점을 증명하는 가장 좋은 방법이 될 것이라고 결정했다.아마도 그것은 통용될 것이다. 그러나 이것은 이해하기 쉬운 용례이다. 대부분의 대학생들이 온라인 상점을 사용한 경험이 있기 때문에 클라우드 도구를 이용하여 어떤 것들을 구축하는 것은 그들이 어떤 유형의 소프트웨어 공학 (또는 적어도 해커 경쟁) 에서의 직업 생활에 도움이 될 수 있기 때문이다.시스템 설계 면접 문제에서 사람들이 얻고자 하는 기능도 포함한다.
이것은 상응하는 블로그 글이 될 것이다. 나는 그 중에서 같은 내용을 포함했지만 디자인 시스템의 경험과 내가 이런 결정을 내릴 때의 사고 과정에 더욱 중심을 두었다.강좌에서는 프로젝트를 설정하고 관련 도구를 사용하는 방법에 더 많은 관심을 기울일 것이다.따라서 이 글에서 제가 어떤 것을 디자인하는 과정이 더욱 혼란스러워지고 나중에 거슬러 올라가 수정하는 것을 보실 수 있습니다.

요구 사항

우리가 상점에서 무엇을 할 수 있기를 바라는 것부터 시작합시다.

우리는 제품을 조회할 수 있어야 한다.우리의 예시에서 우리는 ~3개의 제품을 실현할 수 있다.

우리는 일부 제품을 카트에 추가할 수 있어야 하며 이 카트는 조회 세션에서 변하지 않아야 한다.전방 세계에는 '세션' 에 대한 정의가 많지만, 나는 '세션' 을 가리킨다. 예를 들어 브라우저를 닫고 같은 URL을 다시 방문하는 것과 같다.

세션이 끝날 때 우리는 쇼핑 카트에서 상품을 구매할 수 있어야 하며 이 주문서는 어디에 기록해야 한다.

나는 이것들이 상점의 기본 요소라고 생각한다.물론 간단하게 보기 위해서 나는 많은 세부 사항을 뛰어넘었다.지금까지 제 경력의 대부분은 주문서의 확인과 실현에 주력했지만 이 두 가지는 여기서 쉽게 소홀히 여겨졌습니다.

데이터 저장소

나는 데이터를 어떻게 저장하는지부터 디자인하는 것을 좋아한다.우리가 이미 확정한 수요를 감안하여 우리는 어떤 데이터를 저장해야 하는지를 확정해야 한다.

제품 정보.제품을 탐색하기 위해서, 우리는 고객을 위해 이 제품들에 관한 정보를 표시해야 한다.우리는 목록이라고 부른다.

세션 정보.우리는 고객이 계산 단계에서 카트에 어떤 제품이 있는지 알아야 한다.

주문 정보.우리는 고객이 무엇을 주문했는지, 그리고 어떻게 주문을 완성했는지 알아야 한다.우리는 그것을 실제로 고객에게 운송할 필요가 있지만, 법률과 세무 방면의 원인도 있다.

데이터를 저장하는 방법은 매우 많은데 데이터 저장 자체가 복잡한 주제이지만 다이나마이트로 이 모든 것을 완성할 계획이다.주요 원인은 내가 학생들의 해킹 경기를 돕고 싶어서이다.따라서 프로젝트의 복잡성을 낮추기 위해 서버가 없는 해결 방안을 선택하는 것이 가장 간단하다.DynamoDB나 S3이 남았는데 DynamoDB가 이런 것들에 가장 의미가 있다.비록 서버가 없는 SQL은 이미 존재하기 시작했지만, 나는 NoSQL이 해커 대회에도 가장 의미가 있다고 생각한다. 왜냐하면 우리는 SQL이 진정으로 필요로 하는 해커 대회 기간에 적당한 표 설계를 할 시간이 없기 때문이다.
우리는 여전히 우리가 데이터를 어떻게 구성하고 싶은지 결정해야 하기 때문에 이 디자인의'데이터 저장'은 아직 완성되지 않았다. 그러나 NosQL의 장점 중 하나는 우리가 앞으로 심지어 실현할 때 결정할 수 있다는 것이다. 그래서 나는 API 디자인을 계속 토론할 것이다.

API - 또는 API 정의에 대한 간단한 우회

적어도 내가 대학에 다닐 때 나는 API가 무슨 뜻인지 정말 몰랐기 때문에 여기에는 빠르고 더러운 해석이 있었다.갑골문에 따라 구글 최고법원 사건에 대해 API가 무엇인지 설명하려는 사람들이 많은데, 그들은 항상 API가 응용 프로그램 프로그래밍 인터페이스를 대표한다고 말한다.나는 이 점이 도움이 되지 않는다고 생각하기 때문에 나는 다른 방식으로 그것을 묘사하려고 시도할 것이다.간단히 말하면 소프트웨어는 층 구조를 선호하고 API는 소프트웨어 층 상호작용 방식의 통용 용어이다.
예를 들어, python에서 파일을 쓰기 위해 다음 코드를 사용할 수 있습니다.

with open("text.txt", "w") as file_handler:
    file_handler.write("Some string")

파일을 작성하는 것은 매우 복잡합니다. 이것은 운영체제, 파일 시스템, 심지어 실제 디스크 형식에 달려 있습니다.일반적으로 말하면, 당신은 당신의 운영체제에 요청을 하고, 운영체제는 당신의 파일 시스템에 요청을 하고, 파일 시스템은 당신의 실제 하드웨어에 요청을 한다.
예를 들면 다음과 같습니다.

하지만python은 다음을 사용하든 사용하지 않든 이 문제를 해결해 줍니다.

macOS、APFS、NVME SSD;

Windows, NTFS 및 하드 드라이브,

또는Linux、ext4、SATA SSD

이 python 코드는python의 파일 API로 설명됩니다.이것은python 프로그램과 파일이 상호작용하는 방식입니다.이로써 프로그래머들은 API 디자이너가 만들어준 개념을 이해하기만 하면 모든 부분의 작업 원리를 이해할 필요가 없이 복잡한 시스템을 만들 수 있다.

API 설계

만약 데이터 저장 부분이 이 항목의 명사라면 API는 동사다.우리는 이 데이터로 무엇을 할 수 있습니까?우리는 다시 요구에 따라 이 내용들을 세분화할 것이다.

제품 찾아보기

우선, 우리는 디렉터리 데이터를 읽는 방법이 필요하다.그냥 부를게요.

getProduct: (productId: str) -> (Product)

이것은 productId가 필요할 것입니다. 이것은 uuid이고 JSON가 당신의 제품을 대표할 것입니다.1

고객 카트 세션 저장

이 점에 대해 나는 고객이 제품을 카트에 추가해야 한다고 희망한다.

addToCart: (customerId: str, productId: str) -> ()

카트에 있는 물건 나열 가능;

getCart: () -> List<Product>

카트에서 아이템 꺼내기;

removeFromCart: (customerId: str, productId: str) -> ()

여기서부터 데이터베이스를 직접 사용하지 않고 API를 만드는 장점을 볼 수 있습니다.클라이언트에서 API를 사용하여 데이터베이스에서 데이터를 읽을 수 있지만 이 방식은 고객과 데이터의 상호작용 방식을 제한합니다.

결산하다

체크아웃에 대해서는 이전에 작성한 것과 동일해야 합니다getCart.또한 주문을 작성하는 방법도 필요합니다.

makeOrder: (customerId: str) -> (orderId: int)

makeOrder수령customerId하고 대표int의orderId로 돌아오는 것은 고객에게 볼 수 있는 것이기 때문에 간단한int을 선택하여 그들에게 보여 주었다.
이러한 API에 대해 저는 Lambda가 지원하는 API 스위치를 사용할 계획입니다. 왜냐하면 서버가 없는 것이 Hackathon에서 가장 사용하기 쉽다고 생각하기 때문입니다. (그러나 저도 편견이 있습니다.)

고객 상호 작용

일반적으로 디자인의 이 부분에서 우리는 고객과 이 시스템이 상호작용하는 방식을 상상하고 싶다.웹 응용 프로그램에 있어서, 이것은 그들이 쇼핑하는 데 사용할 웹 페이지가 될 것이다.소프트웨어 엔지니어로서 이 부분의 설계는 통상적으로 앞당겨 완성된 것이다.다행히도 최종 사용자에게 제품 매니저와/또는 사용자 체험 디자이너는 일반적으로 유니버설 인터페이스를 설계하지만 엔지니어는 그것을 실현할 뿐이다.
제 전단 경험이 제한되어 있기 때문에 전단에서 몇 가지 프로젝트만 일했고 전단은 보통 클라이언트에 있어서 클라우드 구조와 상호작용이 많지 않습니다.나는 단지 시범을 보이기 위해 빠른 사이트를 만들었을 뿐이지, 결코 이 디자인 과정에 그것을 포함하는 것은 아니다.2
다음 기사는 AWS를 사용하여 AWS를 설정하는 방법에 대한 안내문입니다.
왜 하나의 숫자가 아니라 uid입니까?고객이 당신의 제품 ID를 추측하기는 어려울 수도 있지만, 경쟁사들도 그것을 이용하여 당신이 얼마나 많은 제품을 가지고 있는지 추측할 수 있다.참조https://en.wikipedia.org/wiki/German_tank_problem↩
또한 나는 두 시간 동안 이 문장에 도형의 html을 박았기 때문에 아마도 나는 전방 개발을 가르쳐서는 안 될 것이다.  ↩