DevBoi

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

각기 다른 도메인들은 독립적으로 발전 할 수도 있지만, 상호작용해야한다. 각 접점이 존재한다. 이를 contract라고 한다. - 협력형 패턴 그룹 - 사용자,제공자 그룹 - 분리형 노선 결재자와 수취자에 대한 개념을 모델링을 했다고 하면, 각각 다른 도메인에 있어, 다른 위치에 있지만, 의미는 같다. 이를 같은 의미인지 통역해주는 과정이 컨텍스트 매핑이다. * 협력형 패턴 * 공유 영역 공유 영역이라고 하면, 라이브러리 영역을 공통으로 포함을 해서 배포를 각각 A,B를 한다. 마이크로 서비스할때는 공유 영역을 최소로 하는것이 중요하다. 대부분의 패턴은 공급자,소비자 패턴을 쓴다고 한다. 정보를 받을때 공급자 입장에서는 upstream, 소비자 입장에서는 downstream이라고한다. 상류의 모델에서, ..

마이크로 서비스를 식별할때 대중적으로 쓰이는 방법이다. 비지니스 도메인 : 기업의 주요활동영역, 회사가 제공하는 서비스 (sub domain) 하위 도메인: 비즈니스 활동의 세분화된 영역, 제공하는 서비스 단위 쉽게 얘기하면, 도메인과 서브 도메인으로 분류할 수 있다. 하위 도메인의 개념 하위 도메인은 도메인을 표현하는 영역이다. * 핵심 -회사가 경쟁업체와 다르게 수행하고 있는 것 -복잡성 높지만 BIz경쟁력 제공 * 일반 - 모든회사가 같은 방식으로 수행하는 비지니스 활동 - 복잡하고 구현하기 어려우나, 경쟁력을 제공하지는 않음, 알려진 영역 - 인증,권한 * 지원 - 회사 비지니스 지원활동 - 기능간단,어떠한 경쟁우위 제공하지 않음 - CRUD, ETL 유비쿼터스 언어 도메인 주도 설계에서는 도메인..

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