はてなブックマーク

public class JankenApplicationService { : public Optional<Player> play(long player1Id, Hand player1Hand, long player2Id, Hand player2Hand) { return tm.transactional(tx -> { val janken = Janken.play(player1Id, player1Hand, player2Id, player2Hand); jankenRepository.save(tx, janken); return janken.winnerPlayerId() .map(playerId -> playerRepository.findPlayerById(tx, playerId)); }); } } ここで気になるのは、Jank

これらのコードでは、Janken と JankenDetail を同時に保存すること・同時に取り出すことがアプリケーション層に依存しています。 もしもアプリケーション層で Janken と JankenDetail が同時に保存・取り出しされないコードが書かれてしまうと、保存されたデータが整合性のない状態になったり、取り出したオブジェクトの一部フィールドが NULL という整合性のない状態になったりします。 Janken と JankenDetail が同時に保存・取り出しされるべきものならば、そのことはモデルとして表現されるべきで、アプリケーション層の実装に委ねるべきではありません。 根本原因 このように Janken と JankenDetail の整合性がアプリケーション層の実装次第になってしまう原因は、Janken と JankenDetail それぞれの DAO をアプリケーショ

はじめに x と y と z を JOIN して COUNT した値を画面に表示したいなど、画面が要請する値を DB からごにょごにょと集計して API で返したくなることがあります。1 そんなとき、DB のモデルをドメインモデルにマッピングし、ドメインモデルを API のインターフェースにマッピングして返すような実装をしていると、以下のような問題にぶつかります。 集計後の値を取得したいだけなのに、大量のオブジェクトをアプリケーションのメモリ上にロードすることになる ちょっと取得する値を追加・変更するだけでもドメインモデルに影響が出てしまう 使っている O / R マッパ によっては N + 1 問題が発生しやすい ドメインモデルを集約単位で扱っていると、アプリケーション上で JOIN の処理を実装することになる この記事では、簡易的な CQRS で上記の問題を解決してみます。 CQRS

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「Controller にビジネスロジックを書くな」と言われることがしばしばあると思います。 この記事では、そもそもそれは何がいけないのか、どうすればいいのかを整理しました。 具体的なコードまでは書いていないですが、各ケースを図で表現して、できるだけ分かりやすいようにまとめました。 「Controller に全部書く」とはどんな状態か 「Controller にビジネスロジックを書くな」の対応の前に、「Controller に全部書く」という状態について整理しようと思います。 この記事で言う**「Controller に全部書

. ├── application │   ├── external │   ├── query │   │ └── user │ │   ├── UserQueryModel │ │   └── UserQueryService │   └── service │   └── user │    ├── UserApplicationService │    └── UserGetOutput ├── domain │   └── model │   └── user │    ├── User │    └── UserRepository ├── infrastructure │   ├── external │   ├── mysqlrepository │   │ └── user │ │   └── UserMySQLRepository │   └── mysqlquery

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? E2E テストの自動化に挑戦するためにツールを調べた結果をまとめました。 「Selenium、Puppeteer くらいは聞いたことがあるけど、他にも良さそうなものがないか調べておこう」という軽い気持ちで調べ始めたところ、想像していた以上に色々ありました。。。 ※ Web フロントエンドの E2E テストが主な対象です。それ以外は、調べて出てきたことだけまとめています。モバイルは調査対象外です ※ E2E テストに詳しくなく、いろいろ間違いがあるかもしれません。お気付きの方はご指摘お願いします。 ざっくりググると ... Seleniu

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? アプリケーション開発で、「ビジネスロジックは分離しろ」だとか「Controller にビジネスロジックを書くな」といったことをよく言われると思います。 しかし、ビジネスロジックという言葉の意味を聞いたり調べたりしてみても、「システムのコアの部分」とか「システムの目的になる処理をするところ」みたいなことを言われたりして、よく分かりませんでした。 そんな中、クリーンアーキテクチャや DDD の戦術的設計について学ぶことで、「ビジネスロジックとは何か」、「ビジネスロジックはどう実装するか」について、自分なりの考えが整理されてきたので、この記事

AWS を使うことが多かった自分が GCP をさわったところ、Cloud IAM に登場する用語が AWS の IAM と違うことで非常に混乱しました。 そこで、過去に AWS の IAM1 や Kubernetes の RBAC2 についてまとめたのと同じように、GCP の Cloud IAM に登場する基本概念をまとめました。 ※ 基本を理解するための記事なので、厳密ではない表現をしている箇所があります ※ Cloud IAM 初心者のため、間違いがあるかもしれません。見つけた方はご指摘ください Cloud IAM に登場する基本概念の全体像 整理した概念の全体像は以下の通りです。 AWS と比べながら順に説明していきます。 各概念の説明 メンバー GCP では IAM によって権限を付与できる対象を「メンバー」と言います。 「メンバー」には、 Google アカウント サービスアカウ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? REST API のテストを自動化するためのツールを調査した結果のまとめです。 前提として、無料で使用可能なツールのみを対象としています。 分類 一口に REST API のテスト自動化といっても、様々な種類のツールがあります。 今回は独自に分類した以下の 4 種類を順に紹介していきます。 OpenAPI (Swagger) 連携系 GUI 系 CLI 系 CDC testing 系 OpenAPI (Swagger) 連携系 REST API の管理として OpenAPI (Swagger) で仕様を記述することは少なくないでしょう。

以下でそれぞれ説明していきます。 SwiftUI vs SwiftUI 登場以前 まず大きな分類として、Swift UI と Swift UI 登場以前の 2 種類の実装方法があります。 Xcode の最近のバージョンで新規プロジェクトを作成しようとすると、User Interface の選択肢に SwiftUI と Storyboard が並んでいます。 この選択肢は、SwiftUI を使うか、それ以前の実装方法を使うかを選ぶのとかなり近いです。 SwiftUI 2019 年に登場した、iOS 13 以降でのみ利用可能な新しい UI 実装方法です。 コードで UI を実装することになります。 ざっくり言うと、Flutter での UI 実装と似ていると言われています。 現時点では細かい UI の再現は苦手な場合もあるようです。 なお、SwiftUI と SwiftUI 登場以前の実装方法

はじめに 書籍『実践ドメイン駆動設計』や『.NET のエンタープライズアプリケーションアーキテクチャパターン』などにおいて、「集約」という概念が非常に重要とは言われていますが、その理由はあまり詳しく解説されていません。 (少なくとも、私は書籍を読んだだけでは分かりませんでした) しかし、ある時データアクセスの実装について考えていたところ、「集約」が様々な課題を解決してくれる重要な概念だということに気付きました。 データアクセスの課題 アプリケーションを実装していると、データアクセスに関するコードで以下のような課題に突き当たることが多々あるのではないでしょうか。 サービスクラスに大量の Repository をインジェクションすることになる オブジェクトの一部だけをロードして、子要素が NULL の状態が生じる データアクセスの設定や記述方法によって N + 1 問題が発生する これは、ある

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに アプケーション・アーキテクチャについて学ぶと「MVC」や「3 層アーキテクチャ」といった言葉にたどり着きます。 さらに勉強を進めると「MVVM」、「ドメインモデル」、「クリーンアーキテクチャ」など、よく分からない言葉がどんどん増えていきます。 また、「オブジェクト指向」を勉強しても、実際のアプリケーションでの使いどころが分からなかったりします。 この記事では、これらの用語の非常に分かりにくい関係を整理しました。 3 層アーキテクチャ 2 種類の 3 層 伝統的な Web アプリケーションは、以下のように 3 種類のサーバから成

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに Testcontainers を使用すると、JUnit のテスト中だけ MySQL のコンテナを起動することができます。 SimpleMySQLTest.java というサンプルコードを見ると結構簡単に使えそうですが、Spring Boot + MyBatis で試してみたら結構苦労したので、どうすれば動くかまとめておきます。 まずは普通に Spring Boot + MyBatis を動かす Testcontainers でテストを試す前に、動くコードを書いておきます。 MyBatis のコードを作成 UserRepositoryImpl.java、UserMapper.java、UserMapper.xml の 3 ファイルを作成します。 package springdockerexample.infrastructure.user; import org.springfra

はじめに Java アプリケーションをコンテナ化するツールに jib があります。 GitHub の README には、Docker のベストプラクティスを知らなくても最適な Docker イメージを作ってくれると書かれています。 Jib builds optimized Docker and OCI images for your Java applications without a Docker daemon - and without deep mastery of Docker best-practices. そんな Jib がどのくらい Docker イメージのベストプラクティスを満たしているのか調査してみました。 準備 検証には、Spring Initializr で作成した Maven プロジェクトを使います。 jib-maven-plugin の README の通り、

ulgeekアドベントカレンダーの11日目です。 何をする記事なのか docker execコマンドなどでコンテナにログインすることなく、ホストからDockerコンテナ内のファイルを操作してみます。 なぜこんなことをしてみようと思ったのか Dockerコンテナ内で見えるファイルは、実際にホスト上のどこかにあるはずです。具体的にどこにあるのか、ホストからどう見えるのか、ホストでの操作がコンテナ内に反映されるのか、確認したい気持ちが湧いてきます。 ということで、実際に確かめてみます。 実行環境 Amazon LinuxにDockerをインストールして検証します。 バージョン Amazon Linux AMI 2017.09 Docker version 17.06.2-ce Dockerインストール手順 $ sudo yum install -y docker $ sudo service d

AWSの無料枠といえばt2.microです。 ということで、EKSをWorkerがt2.micro 1台という構成で構築してみました。1 (2018/06/12) CloudFormationテンプレートのMaxPodsの設定が影響している可能性を考慮していなかったため、追記しました。 結論 EKSのWorkerは、t2.microでも特に問題なく構築でき、Podの起動も可能でした。 ただし、IPアドレス数の制限により、Podは2つ以上起動できませんでした。 IPアドレスが枯渇するとWorkerもPodもスケールできなくなると思われるので、IPアドレス数の制限には注意が必要そうです。 インスタンスタイプごとに、IPアドレス数の制限と、MaxPodsによる制限と、他にも何らかの制限があり、Podの起動数が制限されているようです。 スケールを考えるうえで、Podの起動数の制限には注意が必要そう

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

概要 SESでの開封・クリックのトラッキングについてはいくつか記事がありますが、それをTerraformで実現したという情報はあまり見当たらないのでまとめました。 SESはトラッキングデータをCloudWatch、Kinesis Firehose、SNSに送ることができます。 今回はKinesis Firehose経由でS3に保存します。 SESでの開封・クリックの取得の仕組み 開封・クリックのトラッキングには、HTMLメールを使用する必要があります。 開封のトラッキングは、HTMLメールの末尾に画像が添付されることで実現されます。 クリックのトラッキングは、メール内のリンクがSESによって自動的に書き換えられ、あるURLを経由したリダイレクトとなることで実現されます。 variable.tfの記述 variables.tfに変数を定義します。

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? AWS IAMに登場する概念はややこしく、初学者が理解するのは難しいと思います。 そこで、概念モデルを作成して、AWS IAMの基本概念を整理しました。 ※ 一部の概念はTerraformのリソース名を参考に命名しています。 全体像 AWS IAMに登場する基本概念は、以下のように整理できました。 それでは、以下の3つに分けてややこしい点を説明していきます。 IAM Policy IAM Policy Attachment IAM Role IAM Policy IAM Policyとは、どの「リソース」へのどの「アクション」を許可 (

Webや書籍をざっとあさり、Docker / Kubernetesのセキュリティについて調査したメモ。 ※この他にも多数ありましたが、まずはこのあたりからかな？というものを書き出しています。 Dockerのセキュリティ ベースイメージ 公式イメージを利用する alpineなど、小さなイメージを利用する Docker Content Trustで署名チェックする Dockerfile rootユーザを使わず、実行ユーザを使う 外部のファイルを追加する場合はチェックサムを検証する 機密情報は環境変数など外部から取得する構成にする CI Quay.ioなどでイメージのセキュリティスキャンを行う Docker Bench for Securityで実行環境も含めたベストプラクティスをチェックする ホスト Container-Optimized OSなど、コンテナのホストとして適切なセキュリティ原則