Concepts/SW Architecture22 아키텍처 - 아키텍처 사고 - 출처: 이 글은 도서 '소프트트웨어 아키텍처 101'을 참조하여 작성된글입니다. - 개요 아키텍처 사고는 단순히 '아키텍처를 생각하는것'이라고 많은 오해를 하지만 아키텍처 관점에서 사물을 바라볼줄 알아야 하는것을 의미한다. 아키텍트의 사고방식은 크게 4가지 사고방식으로 나눌 수 있다. 아키텍처와 설계 차이의 이해 기술의 깊이보다는 폭넓은 지식의 이해 다양한 솔루션과 기술간의 Trade off 이해 비즈니스 동인(행동을 촉발시키는 내적 원인의 총칭)의 중요성이해(이 글에서는 다루지 않는다.) - 아키텍처 vs 설계 아키텍처와 설계의 차이점은 모호한 경우가 많다. 이를 이해하기 위해 전통적인(기존 시각의) 아키텍트와 개발자의 책임을 이해해보자. 아키텍트 비즈니스 요구사항을 분석하여 아키텍처의 특성(~성).. 2022. 3. 9. 아키텍처 - 프로젝트 패키지 구조 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 각 프로젝트 마다 규모나 설계자의 생각에 따라 패키지 구조를 정한다. 패키지 구조는 프로그램이 단순히 동작하게 하는데에는 크게 중요하지 않을수도 있지만, 프로그램을 파악하는데 도움이 되며 설계의 사상을 반영한다. - 계층 기반 패키지 가장 단순하고 전통적인 아키텍처다. 기술적인 관점의 계층에 기반하여 코드를 분할한다. 위의 다이어그램은 스프링 MVC 를 처음 시작하거나, 웹 프로그래밍에 경력이 좀 있다면 꽤 익숙할만한 패키지 구조이다. 각 클래스와 인터페이스는 다음과 같은 역할을 한다. OrdersController: 웹 컨트롤러, 웹 요청 처리 OrdersServ.. 2021. 2. 10. 아키텍처 - 서비스와 아키텍처 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 서비스 지향 아키텍처(SOA - Service Oriented Architecture)나 마이크로 서비스 아키텍처(MSA - Micro Service Architecture)라는 말을 들어봤을것이다. 단어만 언급해도 뭔가 전문가가 된것 같고, 심지어 단어 자체도 멋있다. 흔히 이런 아키텍처들의 장점으로 상호 결합을 완벽하게 분리한다거나, 개발 및 배포 독립성을 보장해준다는 문구를 본적이 있을것이다. 하지만 이 역시 진리의 케이스 바이 케이스이다. - 서비스 아키텍처 서비스를 분리한다는건 아키텍처측면에서 무엇인가를 하는것일까? 먼저 우리가 여태까지 "아키텍처"를 언급.. 2021. 2. 10. 아키텍처 - 부분적인 경계 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 아키텍처 경계를 완벽하게 하는데에는 비용이 많이 든다. 양방향으로 인터페이스를 정의하고, 입력과 출력에 대한 데이터 구조를 만들며, 독립적으로 컴파일 및 배포를 할 수 있도록 컴포넌트를 설계하고 의존성을 관리해야 한다. 이런 이유로 어떤 사람들은 경계를 완벽하게 만드는것이 과도하게 선행적인 설계라고 생각한다. 너무 완벽한 경계를 구현하는데 과도한 비용이 들어간다면 경계를 부분적으로 구현하는것을 고려해볼 수 있다. - 단일배포 첫번째 방법으로는 소스는 완벽한 경계를 구현하지만, 단일 컴포넌트로 컴파일해서 배포하는것이다. 이렇게 되면 코드는 간단해지지 않지만 의존성이나.. 2021. 2. 10. 아키텍처 - 프레젠터와 험블객체 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 험블 객체: https://martinfowler.com/bliki/HumbleObject.html - 험블 객체 패턴 프레젠터는 험블 객체 패턴을 따른다. 험블(humble)이란 사전적으로 보잘것없다는 의미를 지니고 있다. 험블 객체 패턴은 디자인 패턴으로 테스트하기 어려운 행위와 쉬운 행위를 분리하는 패턴이다. 뷰와 엮인 경우 테스트 하기 어려운 부분이 존재하는데, 테스트하기 쉬운 영역과 어려운 영역으로 나누면 프레젠터와 뷰라는 클래스로 나뉘게 된다. - 프레젠터와 뷰 사전적인 의미로 생각해보면 프레젠터와 뷰는 비슷한 느낌이 든다. 하지만 설계 관점에서 이 두 가지를.. 2021. 2. 10. 아키텍처 - 클린 아키텍처 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 지난 수십년간 많은 시스템 아키텍처가 있었다. 이런 아키텍처들은 공통된 목표가 있는데 바로 관심사의 분리이다. 이들은 모두 소프트웨어를 계층으로 분리하였다. 업무규칙에 대한 계층과, 사용자 및 인터페이스를 위한 계층등이 있다. 또한 업무규칙이 아닌 다른 요소와의 독립성도 강조한다. 프레임워크 독립성: 아키텍처는 프레임워크의 존재 여부에 의존하지 않는다. 테스트 용이성: 업무규칙은 외부요소없이도 테스트가 가능해야 한다. UI 독립성: 업무규칙을 변경하지 않고도, UI를 쉽게 변경할 수 있어야 한다. 데이터베이스 독립성: 업무규칙에 영향을 주지 않고, 데이터베이스를 변.. 2021. 2. 10. 아키텍처 - 아키텍처의 오해 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 만약 어떤 건물에 대한 설계도를 본다고 해보자. 해당 설계도에 독서 공간, 회의실, 책장을 배치한 많은 진열장이 있다면 정확히는 몰라도 도서관이라고 추측할것이다. 어플리케이션을 만들기 위해 패키지 구조를 잡았다고 하자. 좋은 아키텍처라면 어떤 사람이 해당 패키지 구조를 보았을 때 "이 어플리케이션은 헬스 케어 시스템이다" 라고 생각하게 만들어야 한다. 만약 패키지구조를 보고나서 드는 생각이 스프링으로 구현했나? ASP인가? 하이버네이트를 사용했나? MySQL인가? 라는 생각이 들도록 만들었다면 제대로된 아키텍처인지 다시 한번 생각해볼 필요가 있다. - 목적 나를 포.. 2021. 2. 10. 아키텍처 - 정책과 수준 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 소프트웨어 시스템 및 아키텍처를 정책이라는 관점에서 무엇인지 생각해보고, 여태까지 살펴보았던 내용을 돌이켜보자. 소프트웨어 시스템이란 입력을 출력으로 변환하는 과정의 정책을 상세하게 기술한것이다. 또한 하나의 큰 정책은 작은 여러 정책으로 나누어지며 아키텍처라는것은 이런 정책을 분리 및 재배치 한다. 같은 시점에 같은 이유로 변경되는 것들을 하나의 컴포넌트로 모으고, 다른 시점에 다른 이유로 변경된다면 분리한다. 하나의 컴포넌트는 다른 컴포넌트에 의존한다. 컴포넌트를 정점으로, 의존성을 방향이 있는 간선으로 본다면 방향그래프로 나타낼 수 있다. 이 때 비순환이 되도.. 2021. 2. 10. 아키텍처 - 경계 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 소프트웨어 아키텍처는 경계 설정을 잘해야 한다. 경계는 요소를 분리하며, 특정 요소들끼리 서로 알지 못하게 한다. 어떤 경계 설정은 초기에 이루어 지며 어떤 경계 설정은 나중에 이루어진다. 초기의 섣부른 결정은 불필요한 결합을 만든다. 유스케이스와 관련없는 결정들, 예를 들어 프레임워크, DB, 웹 서버, 유틸리티 라이브러리등이 있다. 좋은 아키텍처는 이런 요소를 부수적인것으로 만들 수 있으며, 이런 결정을 최대한 미룬다. 또한 이런 결정이 변경됨에 따른 영향도가 크지 않게 만든다. 경계는 관련이 있는 것과 없는 것 사이에 긋는다. GUI, 업무규칙, 데이터베이스 .. 2021. 2. 10. 컴포넌트 결합 - SAP (안정된 추상화 원칙) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 고수준의 정책 컴포넌트는 안정된 정도만큼만 추상화 되어야 한다. 시스템에서 업무규칙은 안정된 (I = 0, 즉 불안정성이 작은) 컴포넌트여야 한다. (I 개념을 모른다면 ocwokocw.tistory.com/37 글을 먼저 숙지해야 한다.) 업무규칙은 고수준의 정책이기 때문이다. 반면 불안정한(I = 1) 컴포넌트는 변동성이 큰 컴포넌트여야 한다. 이 문장만 읽었을 때 이상함을 느껴야 한다. "업무규칙은 안정된 컴포넌트 여야 한다"는 말이 당연한 얘기인가? 앞서 SDP 원칙에서 안정된 컴포넌트는 변경을 하기가 어렵다고 하였다. 그런데 SOLID 원칙에서는 고수준의 시스템.. 2021. 2. 10. 이전 1 2 3 다음
