콩딱일상

사실 헥사고날 아키텍쳐는 별도의 책이 존재할 정도의 내용이다. 만들면서 배우는 헥사고날 아키텍처 설계와 구현 (책) 앨리스터 코번이 2005년에 헥사고날 아키텍처를 소개하였다고 합니다.핵심내용비즈니스 로직이 외부의 기술적 구현 세부 사항(데이터베이스, UI, 외부 API)등과 철저히 분리되어야 한다핵심 비즈니스 로직이 다른 의존성 없이 자신의 역활에만 집중해야 한다. 해당 책에서는 어뎁터 포트 그러한 헥사고날의 전반적인 내용은 설명하지 않습니다. 아래의 링크를 보면은 그래도 친절히 설명해 주신것 같아서 좋았습니다.https://www.youtube.com/watch?v=MKfSLrwLex8   해당 도메인 주도 설계도 기술에 의존하지 않는 도메인 객체를 강조하기 때문에 헥사고날 아키텍처의 목표와 동일하다..

복잡한 비즈니스 로직과 데이터 처리를 효과적으로 관리하기 위한 방법을 찾는 과정에서 비롯되었다.모든 비즈니스 로직을 서비스 레이어 한곳에 구현하면 가독성이 떨어지고 유지보수하기 어려워지는 한계점이 나오게 된다.서비스 레이어와 비즈니스 규칙 예public class XXService { public void addItem(String id, String productNo, String productName, int quantity) { int size = Dao.selectItemSize(id); if (size > 10) { throw new RuntimeException("..."); } ... }} 도메인 모델 패턴데이터와..

사용자 인터페이스, 데이터 조회와 저장도 중요하지만 다른 시스템과의 통합도 중요합니다.Service Layer로 부르는 독립된 클래스에 시스템 통합과 전체 흐름을 조정하는 책임을 부여 합니다.책에서는 현대 소프트웨어에서 가장 많이 사용되는 패턴이라고 합니다.레이어드 아키텍쳐에서 가장 많이 사용되는 패턴인가?단점서비스 레이어의 책임은 여러 리소스간 통합과 통합 결과에 따른 흐름 조정이라, 여러 책임을 지닐수 있기 때문에 복잡도가 증가 할수 있다.   서비스 발행 레이어는 서비스 레이어를 변경 없이 다양한 프로토콜을 요구하는 클라이언트를 지원하게 확장 가능하다고 한다.이 부분은 서비스 발행 레이어는 수정이 필요하다는 것입니다. 서비스인 비즈니스 로직은 변경이 필요없지만 결국 다양한 프로토콜을 받아들여서 서비..

Table Module은 DB의 테이블 단위로 비즈니스 로직을 처리하는 클래스로 분리를 합니다.전체 비즈니스의 흐름은 DB 테이블 단위의 클래스를 이용하여 처리 합니다.JDBC(Java Database Connectivity)가 제공하는 ResultSet이나, RecordSet, DataSet을 선언하고 기능을 추가해서도 사용합니다.import java.sql.Connection;import java.sql.PreparedStatement;import java.sql.ResultSet;import java.sql.SQLException;// User 테이블을 관리하는 테이블 모듈public class UserTable { private Connection connection; // 생성자를 통..

자세한 내용은 아래의 링크를 통해서 확인하면 된다. JWT.IO JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. jwt.io 아래와 같은 구성으로 되어 있다. 인증을 위한 정보와 PayLoad가 포함되어 있어서 인증을 기반으로 동작하는 Token이라는 것이다. 개념은 매우 심플하다.

리스트 컴프리핸션은 파이썬을 사용하는 사람들이 길게 쓰는걸 싫어해서 줄인 표현식 같은걸로 생각됩니다. 그런데 이게 가독성이 좋은지는 사실 잘 모르겠기 합니다. 우선 Syntax는 조금 복잡해 보일수 있지만 아래와 같습니다. [표현식 {조건식} 반복문(1..*) 추가 조건식] 몇번 테스트를 돌리다 보니까 이게 맞는것 같은데 정확하진 않습니다. 아래의 예제는 https://docs.python.org/3.10/tutorial/datastructures.html 에서 가져왔습니다. [(x, y) for x in [1,2,3] for y in [3,1,4] if x != y] for x in [1,2,3] for y in [3,1,4] if x != y: append((x, y)) 이렇게 보면은 참 이해하기 쉬..

Factory Pattern이라고 많이 사용하였지만, 실제로는 Simple Factory Pattern만 계속해서 사용한것 같다. 사실 원리는 아주 간단하다. 헤드퍼스트 예제에서는 PizzaStore를 통해서 예제가 나온다. 이게 간단하기 때문에 그냥 이용하면 된다. class PizzaStore { public: Pizza orderPizza(string type) { Pizza pizza = createPizza(type); pizza.prepare(); ... return pizza; } protected: //예제는 protected인데 사실 private로 하여도 문제는 없을것 같은데... virtual Pizza createPizza(string type) = 0; } class NYPizza..

사실 매우 광범위 하기도 하면서 한편으로 귀찮고 어려운게 바로 의존성을 관리하는 거라고 생각된다. 그래서 아예 의존성을 카테고리로 만들어 버렸다. SOLID원칙은 굳이 이야기 하지 않아도 될것이라 생각한다. interface를 정의하고 사용한다는것 상세한 구현이 아니라 명세?에 의존해야 한다는것 실제로 적용을 해보면 막막한 부분들이 나오는것 같다. interface로 구현한다는건 결국 세부 구현에 대한 의존을 줄이고, 변경 가능하고, 유연한 기능을 제공하기 위한 것으로 생각된다. 유연하고 변경가능하다. 결국 확장성, 유지보수성, 작업의 분배, 테스트 와 관련이 있는것 아닐까? 실무에서 정해진 스팩이 있는 상황에서 무조건 유연해야 하는지는 약간 의문이 들때가 있다. 물론 변경 가능할수도 있다는건 알고 있다..