brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Aug 25. 2022

개체(시스템)의 재설계와 경계의 변경

도메인 모델링 세미나 15

최근에 맥락(Context)경계 설정에 대해 생각하고 글을 쓰면서 얻게 된 영감이 있다. 경계를 설정하는 일이 바로 무언가를 정의하는 일이기도 하다는 점이다.


특성과 역할과 관계로 구성요소를 개체로 정의하기

<Context와 컴포넌트와 이상적인 아키텍처> 편에 단락 제목으로 '해당 개체의 중심에 무엇이 있느냐?'라는 문구를 쓴 적이 있다. 만두는 빚는 것과는 매우 다른 일이지만, 구성요소가 있고 그걸 빚어낸다는 점에서 소프트웨어를 만드는 일도 비슷하게 생각할 수 있다. 그리고 '빚어낸다'는 표현을 조금 더 정교한 문장으로 써보니 마음에 든다.

설계자는 특성과 역할과 관계로 구성요소를 개체로 정의할 수 있다.


특성개체가 갖는 요소이지만 관계는 그렇지 않다. 복수의 개체가 존재할 때만 관계는 성립한다. 그리고, 관계를 맺으면 그때 역할이 생겨난다. 관계 속에서 각 개체에 부여된 책임을 객체에 부여한 이름을 역할이라고 할 수도 있다.


개체를 규정하는 일과 경계

기존의 비슷한 생각을 했던 기록을 찾다가 <1 이라는 수와 경계 그리고 단위의 문제>를 찾았다. 그리고 거기서 흥미로운 질문을 발견했다.

제주도는 하나의 섬인가? 비양도나 우도는 제주도가 아닌가?


경계를 짓는 일은 구성이라는 관점에서 보면 무엇을 넣고 뺄 것인가에 대한 결정이다. 앞서 사용한 표현을 쓰면 특성 중에서 넣을 것과 뺄 것을 정하는 일이다. 그러나 개체가 단독으로 존재하는 상황이 아니라면 (사실 대부분의 경우가 그렇다) 다른 개체와의 관계를 정하는 일도 경계를 짓는 일의 일종이다.


<1 이라는 수와 경계 그리고 단위의 문제> 편에 이를 표현하는 (최봉영선생님의) 생각과 그림도 등장한다.


경계 설정은 소프트웨어 설계의 핵심 활동

물리적인 세상과 소프트웨어로 규정하는 세상의 분명한 차이가 있다. 소프트웨어는 경계를 바꾸는 일이 물리적인 세상에 비하면 너무나도 쉽다는 점이다.

출처: https://brunch.co.kr/@graypool/544

그리고 시스템이 지속적으로 생명력을 가지려면 설계 변경이 필요하다. <경계 설정은 소프트웨어 설계의 핵심 활동> 편에 쓴 대로 경계 설정은 설계의 핵심이기 때문에 종종 경계를 바꿔야 할 수도 있다. 관계에 맞춰서 개체의 역할이 달라질 수도 있고, 물리적 세계에서는 불가능하지만 특성에 따라 개체를 다시 규정할 수도 있다.


세상과 호흡하며 적절함을 찾아가기

이 글을 쓴 계기는 페북에서 박종윤님 글을 다시 읽으며 얻은 영감에서 비롯되었다. 물론, 박종윤님 글은 소프트웨어에 대한 이야기는 아니다. 마케팅에 대한 이야기라고 추정하는데, 소프트웨어가 지속할 수 있는 방법과 굉장히 유사한 교훈을 담고 있다.

앞서 설계를 하며 경계를 변경해야 할 수도 있다고 말했는데, 나는 이를 가드닝이라 부르기 좋아한다. (진짜 정원이 아니라) 소프트웨어 가드닝을 할 때 박종윤님의 교훈을 활용할 수 있을 듯하다. 세상과 호흡하며 적절함을 찾으라는 교훈[1]은 소프트웨어 가드닝 제1원칙으로 삼아도 좋을 듯하다.


소프트웨어가 세상과 호흡하기 위해 해야 할 일을 릴리스하여 피드백을 받는 일이다. 이전 글에서 나는 <일단 릴리즈를 하라>고 쓴 일이 있다. 릴리즈를 하고 얻은 피드백이 설계에 대한 충분한 영감을 준다. 박종윤님 글에서 프레임은 소프트웨어 세상에서는 경계에 바로 대응한다. 경계가 한번 지어졌다고 그걸 그대로 두지 않을 수 있어야 한다.


주석

[1] 세상과 호흡하며 적절함을 찾으라는 교훈은 최근에 회사 경영을 하며 훨씬 더 절절히 배우는 점이긴 하다.


지난 도메인 모델링 세미나 연재

1. 도메인 모델링? 비즈니스 모델링 어떻게 하나요?

2. 도메인 모델링 활용의 기본 아이디어

3. 데이터 제품 접근방식과 그 표현

4. 아키텍처는 의사소통에 관한 문제라서?

5. 아주 이상적인 아키텍처

6. 모델 저장소의 의미와 구현

7. 리팩토링을 내장할 수 있다면?

8. Repository 의미 더 찾아 보기

9. 도메인 모델링에서 맥락은 왜 필요한가?

10. Repository 빌딩 블록에 대해 생각해보기

11. 맥락은 어떻게 표현할 것인가?

12. 경계 설정은 소프트웨어 설계의 핵심 활동

13. Context와 컴포넌트와 이상적인 아키텍처

14. Context와 그 시점 문제인지 여부

작가의 이전글 Context와 그 시점 문제인지 여부
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari