의존성6 Go - called module 과 caller module 참조: https://go.dev/doc/tutorial/call-module-code 개요 이번에는 2 개의 Go 모듈을 만들어 본다. 처음에는 다른 라이브러리나 어플리케이션에서 import 되도록 하는 모듈을 만들고, 그 다음에 이를 호출하는 호출 어플리케이션 모듈을 만든다. 호출되는 모듈 만들기 Go 코드는 package 로 그룹화되고, package 는 module 로 그룹화 된다. 모듈은 코드를 실행하는데 필요한 종속성과 Go 버전, 해당 코드가 필요한 모듈의 집합을 정의한다. 일반적으로 모듈에 기능을 추가하거나 개선하면 모듈의 새로운 버전을 배포한다. 만약 내가 작성한 모듈의 기능을 호출한 사용자가 있다면 해당 사용자는 갱신된 package 를 import 하고 운영에 배포하기 전에 새로운 버.. 2021. 11. 28. 아키텍처 - 클린 아키텍처 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 지난 수십년간 많은 시스템 아키텍처가 있었다. 이런 아키텍처들은 공통된 목표가 있는데 바로 관심사의 분리이다. 이들은 모두 소프트웨어를 계층으로 분리하였다. 업무규칙에 대한 계층과, 사용자 및 인터페이스를 위한 계층등이 있다. 또한 업무규칙이 아닌 다른 요소와의 독립성도 강조한다. 프레임워크 독립성: 아키텍처는 프레임워크의 존재 여부에 의존하지 않는다. 테스트 용이성: 업무규칙은 외부요소없이도 테스트가 가능해야 한다. UI 독립성: 업무규칙을 변경하지 않고도, UI를 쉽게 변경할 수 있어야 한다. 데이터베이스 독립성: 업무규칙에 영향을 주지 않고, 데이터베이스를 변.. 2021. 2. 10. 아키텍처 - 경계 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 소프트웨어 아키텍처는 경계 설정을 잘해야 한다. 경계는 요소를 분리하며, 특정 요소들끼리 서로 알지 못하게 한다. 어떤 경계 설정은 초기에 이루어 지며 어떤 경계 설정은 나중에 이루어진다. 초기의 섣부른 결정은 불필요한 결합을 만든다. 유스케이스와 관련없는 결정들, 예를 들어 프레임워크, DB, 웹 서버, 유틸리티 라이브러리등이 있다. 좋은 아키텍처는 이런 요소를 부수적인것으로 만들 수 있으며, 이런 결정을 최대한 미룬다. 또한 이런 결정이 변경됨에 따른 영향도가 크지 않게 만든다. 경계는 관련이 있는 것과 없는 것 사이에 긋는다. GUI, 업무규칙, 데이터베이스 .. 2021. 2. 10. 컴포넌트 결합 - SDP(안정된 의존성 원칙) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 더 안정된쪽으로 의존하라. 프로그램이 완성되거나 유지보수됨에 따라 설계는 계속 변한다. 초기에 변동성이 큰 컴포넌트를 만들었다고 가정하자. 추후 변경이 쉽지 않은 컴포넌트가 변동성이 큰 쪽에 의존한다면 어떨까? 변동성이 큰 컴포넌트를 변경하면 변경이 쉽지 않은 컴포넌트도 영향을 받으므로 변경이 어렵게 된다. SDP(안정된 의존성 원칙)를준수하면 변경하기 어려운 모듈이 변경이 쉬운 모듈에 의존하지 않도록 만들 수 있다. - 안정성 안정성이란 여러가지 의미가 될 수 있다. 책을 세웠다고 가정해보자. 이 책을 쓰러트리려면 대단한 수고를 들여야할까? 그렇지 않다. 손가락 .. 2021. 2. 10. 프로그래밍 패러다임 - 객체지향 프로그래밍 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 객체지향이란? 객체지향 (Object Oriented)은 프로그래머라면 당연히 들어봤을법한 너무도 유명한 개념이다. 객체지향이란 무엇인가? 어떤 사람들은 데이터와 함수의 조합이라고 정의한다. 하지만 이렇게 정의하기엔 너무 단순하고 객체지향 이전에도 데이터 구조를 함수와 조합해서 사용해왔다. 또는 실제 세계를 모델링하는 방법이라고 정의한다. 이 정의는 앞의 정의보다 더 심오하긴 하지만 너무나 모호하다. 보통 OO의 정의를 설명하기 위해 캡슐화, 상속, 다형성을 언급하기도 하는데 이는 하나씩 자세히 살펴볼 필요가 있다. - 캡슐화 OO정의에서 캡슐화를 언급하는 이유는 OO .. 2021. 2. 10. UML - 패키지 다이어그램 - 구현 - 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다. - 패키지 구현(Realization) 특정 패키지가 인터페이스를 정의하고 다른 몇 개의 패키지들이 구현하는 경우가 있다. 위의 다이어그램에서 데이터베이스 게이트웨이 패키지에서 인터페이스를 정의하고 나머지 Oracle, SQL Server, Test Stub 이 이를 구현하였다. 이렇게 사용자와 클래스 사이에 인터페이스가 낀다는건 의존성을 끊는다는 의미가 된다. 만약 여러가지 물건의 전원을 켜고 끄는 리모컨을 개발한다고 생각해보자. 여러가지 물건에 대해 작동이 되어야 하지만 의존성이 생기는것은 원하지 않을것이다. 위의 다이어그램에서 Button과 CheckBox는 OnOff 인터페이스에 의존하여 난로와 조명기구의 전원을 제.. 2021. 2. 10. 이전 1 다음
