DevBoi

Aggregate 패턴은 도메인 모델 패턴이라는 거대한 개념에서, 좀더 세분화 된 모델링을 할 수 있다. 거대한 도메인 모델 패턴에서 적당히 쪼개야 하는데 Aggreagte개념으로 좀더 세분하게 쪼개는 것이다. 도메인 모델은 행위 + 자료구조를 통해 비지니스 로직을 구현한다. 도메인 모델은 POJO로 구성한다. Aggreate가 뭘까? 서비스에서는 행위를 기준으로 도메인을 호출하는데 이를 서비스 단위로 Aggregate단위로 묶는것이다. 몇가지 타입을 공통으로 모델링을 해서 사용하라고 가이드를 한다. Value object 란 뭘까? DTO와 비슷해 보이지만, DDD에서는 해당 valueobject는 DTO와 다르다. 개념적으로 완전한 하나를 표현하고, 고유의 식별자를 가지지않는다. 저 3가지 중에 Co..

개체 모델을 만들고, 행위를 그 안에서 선언 서비스에서는 해당 행위에 대한 선언으로 로직을 처리한다. 액티브 레코드 패턴은 행위가 getter,setter,save()만 있는 것을 의미한다. 바람직한 것은 행위가 엔티티안에 들어가서 비즈니스 로직에 대한 처리를 담당해주는 것이 좋다. User라는 엔티티가 있다고 하면 주소변환에 대한 메소드 행위를 Member entity안에 넣는 것이다. 예를 들면 @Getter @Setter class Member{ private String city; private String dong; public void 주소바꾸기(String city,String dong){ this.setCity(city); this.setDong(dong); } } 뭐 이런식으로 진행이 되..

aggregate - 데이터 요소 command - api 후보 전통적인 방법 인 트랜잭션 스크립트 패턴이 있다. 트랜잭션 단위로 데이터베이스를 작업하는 것이다. 절자 지향 스크립트로 구현하고, 데이터베이스 직접 접근도 가능하다. -> 트랜잭션 간 비즈니스 로직이 중복 되기 쉽다, 추후 유지보수가 어려워진다. 이런 코드의 패턴은 무조건 거부는 아니고 유지보수하는데 불리하게 발전될 가능성이 높다. 왜냐면 최근 방문일시를 update하고 방문을 insert하는 것은 결국 추후에 if,else로 길게 발전될 가능성도 높고 각각의 메소드가 다른곳에서 중복적으로 사용될 가능성도 높기 떄문이다. 또한 만약에 코드에 sql 문이 있다면, DB의 기술에 대한 종속성이 존재해 버린다. 따라서 이런 코드는핵심 도메인 코드..

모놀리스 시스템이다. 3티어로, 클라이언트는 서버를 통해, 데이터 베이스를 호출하고 서버는 한덩어리로 구성되어있다. 레거시 적인 시스템의 문제는 있다. -한꺼번에 수정 배포되어야 해서, 다운타임이 전체적으로 존재한다. -하나 실패되면, 모두 실패된다. -단일 프로세스를 실행한다. -애플리케이션이 한덩어라로 구현이된다는 것 자체가 문제이다. -스케일아웃에 대한 진행이 전체적으로 다 진행이 되어야 한다. 또한 저장소마다 격리가 되어있기 때문에, 저장소별 스케일업이 가능하며, 각 저장소는 API에 대해 캡슐화된 장점이 있다. 또한 뭐.. 여러가지 언어로 API 및 저장소를 캡슐화 할수 있다는 것이 좋다.