// 1. make int to binary
String binaryStr = "";
int tempN = N;
while(true){
if(tempN == 0){
break;
}
int div = tempN % 2;
binaryStr = div + binaryStr;
tempN = tempN / 2;
}
// 2. split by 1
String [] arr = binaryStr.split("1");
int arrCount = 0;
// 3. if end of string is 0
if(binaryStr.substring(binaryStr.length()-1).equals("0")){
arrCount = arr.length-1;
}
// 4. if end of string i 1
else{
arrCount = arr.length;
}
// 5. find max length
int max = 0;
for(int i = 0 ; i < arrCount ; i++){
if(max < arr[i].length())
max = arr[i].length();
}
풀이
1. 10진수를 2진수의 문자열로 변환한다.
2. 1번에서 만든 결과를 문자 "1"을 기준으로 분할시킨다.
3. (예외처리) 1의 자리 값이 0이라면, 2번에서 생성된 배열의 마지막 값은 사용할 수 없다.
4. (예외처리) 1의 자리 값이 1이라면, 2번에서 생성된 배열의마지막 값을 사용할 수 있다.
기본적인 틀은 MSA Batch Server이다. 하지만 API 서버에도 동일하게 적용할 수 있다.
위 그림에서는 이해를 돕기 위해 Aggregate에서 전달, 반환용 객체는 Aggregate의 범위에서 외부로 걸쳐있는 것처럼 묘사하였다.
순번대로 설명을 하면
1) 스케쥴 예약이 된 Batch 서버에서 요청을 담은 Queue로부터 요청을 Pop하여 추출한다.
2) Pop한 요청에 해당하는 Service Method를 호출한다.
3) Service Method는 Domain Aggregate에 Primary Key를 전달한다.
4) 전달된 Primary Key를 가지고 Aggregate 내에 구현되어있는 실질적인 Service Logic을 실행한다.
5) 실행된 Service Logic의 결과를 정해진 반환 객체 형태로 변환한다.
6) 반환 객체 형태로 변환된 결과값을 반환한다.
7) 3)의 과정을 다른 Aggregate에서 진행한다.
8) 4)의 과정을 다른 Aggregate에서 진행한다.
9) 5)의 과정을 다른 Aggregate에서 진행한다.
10) 6)의 과정을 다른 Aggregate에서 진행한다.
11) 3~6, 7~10의 과정으로 반환받은 결과를 정리하여 실행 성공 여부를 반환한다. (API 서버였다면 정리된 결과를 클라이언트에게 반환하면 된다.)
이전의 최소 설계와 다른 점은?
이번에 중점을 둔 구간은 3~6번의 과정을 다루는 Aggregate의 구간이다. 최소 적용했던 이전 설계는 Service Class에서 모든 Service Logic을 담고 있기 때문에, Business Logic 별 Service Logic의 정리가 되어 있지 않았다. 그로 인한 Service Logic의 재활용도가 낮았고, Service Class 간의 호출에도 유동적으로 대처할 수 없었다.
하지만 위 구조로 재설계하면 실질적인 Service Logic은 Domain Aggregate내에 위치하게 되며, Service Class는 Domain으로부터 빌려오기만 하면 된다.
단점은 없을까?
1) 개발 단계에서 Domain, Service Class간 설계에 신경을 많이 써야 한다.
2) 설계의 실수가 발생한 채로 운영까지 배포하게 되면 되돌리기 위한 추가 공수가 발생하게 된다.
3) Domain과 Service Class 사이의 명확한 경계를 제안하는 명세가 필요하게된다.
서버 프로젝트의 구성은?
Aggregate를 적용하기 전에는 Service Package들이 각각 Service Logic과 그에 해당하는 sql들을 보유했다.
하지만 그 역할을 각 Domain이 맡게 되면서 Service Class는 필요한 기능을 명세하는 수준의 코드가 되고, Domain Aggregate의 영역에 Service Logic이 포함되기 때문에 명세와 로직의 구분을 눈으로 볼 수 있도록 위와 같이 분리 시켰다.
위 구상의 적용은 가능할까?
개인 프로젝트로는 위 구성으로 만들어봤자, 이 구조를 위한 프로젝트를 만들어질 뿐이다. 그래서 현재 실무에서 적용할 수 있을지 생각해봤는데, 마침 딱 좋은 프로젝트가 있다.
