OCP3 아키텍처 - 정책과 수준 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 소프트웨어 시스템 및 아키텍처를 정책이라는 관점에서 무엇인지 생각해보고, 여태까지 살펴보았던 내용을 돌이켜보자. 소프트웨어 시스템이란 입력을 출력으로 변환하는 과정의 정책을 상세하게 기술한것이다. 또한 하나의 큰 정책은 작은 여러 정책으로 나누어지며 아키텍처라는것은 이런 정책을 분리 및 재배치 한다. 같은 시점에 같은 이유로 변경되는 것들을 하나의 컴포넌트로 모으고, 다른 시점에 다른 이유로 변경된다면 분리한다. 하나의 컴포넌트는 다른 컴포넌트에 의존한다. 컴포넌트를 정점으로, 의존성을 방향이 있는 간선으로 본다면 방향그래프로 나타낼 수 있다. 이 때 비순환이 되도.. 2021. 2. 10. 컴포넌트 결합 - SAP (안정된 추상화 원칙) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 고수준의 정책 컴포넌트는 안정된 정도만큼만 추상화 되어야 한다. 시스템에서 업무규칙은 안정된 (I = 0, 즉 불안정성이 작은) 컴포넌트여야 한다. (I 개념을 모른다면 ocwokocw.tistory.com/37 글을 먼저 숙지해야 한다.) 업무규칙은 고수준의 정책이기 때문이다. 반면 불안정한(I = 1) 컴포넌트는 변동성이 큰 컴포넌트여야 한다. 이 문장만 읽었을 때 이상함을 느껴야 한다. "업무규칙은 안정된 컴포넌트 여야 한다"는 말이 당연한 얘기인가? 앞서 SDP 원칙에서 안정된 컴포넌트는 변경을 하기가 어렵다고 하였다. 그런데 SOLID 원칙에서는 고수준의 시스템.. 2021. 2. 10. 설계원칙 - SOLID(OCP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle - 개요 소프트웨어 개체(클래스, 모듈, 함수)는 확장에는 열려있어야 하며, 변경에는 닫혀 있어야 한다. 즉, 개체의 행위는 확장할 수 있어야 하지만 이때 개체를 변경해서는 안된다. 만약 요구사항 확장하는데 기존 소프트웨어를 많이 수정해야 한다면 안된다는것이다. - 예제 특정 데이터를 가공하여 웹 페이지에 보여주는 시스템이 있다고 하자. 이때 갑자기 이해관계자가 PDF나 Excel 로 보여줄 수 있게 기능을 추가해달라고 한다. 이때 소스코드를 얼마나 변경해야 할까?.. 2021. 2. 10. 이전 1 다음
