はてなブックマーク

はじめに DDDとは？という議論が尽きません。 「レイヤードアーキテクチャ、Repositoryなどは軽量DDDでありDDDではない」 「ユビキタス言語に基づいたドメインモデリングこそDDDの本質である」 とは言うものの、レイヤードアーキテクチャから先行して理解することが多いのが実情です。 なぜドメインモデリングの導入が進まないことが多いのか考えてみると、初学者にはドメインモデリングを実施したときの最終的な実装とそうでないときの実装の差がわかりづらく、どのような価値があるのかがわかりづらいためだと思います。 **「ドメインモデリングをしたからドメインが素晴らしく良い実装になった」という例を紹介できればいいのですが、なかなか適切な具体的な例で説明することが難しいです。 そこでモデリングよりも技術的な視点にはなってしまいますが「集約を意識したDDDな実装とDDDではない実装」**を具体的に紹介

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Clean Architectureやレイヤードアーキテクチャでは、どのようにレイヤーを定義するかついては言及されています。 そのような中usecase(レイヤードアーキテクチャではApplication層)をどのように実装するべきかについての議論は少ないです。 しかし私はリーダブルなアーキテクチャを実現するために、一番大切なことはusecaseを適切に実装することであると考えています。 そこでusecaseを実装する上で起こりがちな抽象度の問題を例に、リーダブルなアーキテクチャを考えいていきたいと思います。 サンプル 1:1

はじめに 近年Web技術は様々な選択肢が存在しています。その中でユースケースに応じて適切に技術選択することがプロダクトのためにはとても大切です。 エンジニアの興味関心だけで不要な技術選択をして、開発速度やユーザ体験の低下は起きていないでしょうか？ また技術選択をするときに正しい言語化をできているでしょうか？ コンポーネント開発をしたいから、Reduxを採用する SPAにしたいから、Reduxを採用する 単一フローを採用したいから、Reduxを採用する React Hooksの登場でReduxは必要なくなった これらはすべて適切な説明ではありません。 今回は、React、SPA、Flux、Reduxをそれぞれ採用している方が、改めてその技術選択をしていることを言語化できているかの確認になればと思います。 Reactを採用するべきか？ Reactの価値は宣言的UI、コンポーネント開発にあります

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

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

はじめに React HooksはReact 16.8 で追加された新機能であり、state などの React の機能をクラスを書かずに使えるようになります。 React Hooks以前は、ロジックの再利用がコンポーネントに依存してしまいロジック単独でのモジュール化が難しいという問題がありました。 しかしReact Hooksのカスタムフックという独自のフックを作成する機能を使うことで、Viewに依存することなくロジックだけを再利用することができるようになります。 この記事では、v1からv6まで改善していく様子を見て頂くことでReact Hooksの利用方法を紹介します。 今回の実例ではコンポーネントのコード量は以下のように削減されます。 実例紹介 コンポーネント間のページネーションを実装するuseLocalHistoryカスタムフックを作成します。 ブラウザのhistory APIのよ

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

日本語情報 xerrors パッケージ Goの新しいerrors パッケージ xerrors xerrors - エラー設計の注意点 xerrorsパッケージがWrapメソッドではなく : %w でラップする理由 xerrors パッケージ - 独自に定義したエラー型はIsメソッドとAsメソッドでデフォルトの振る舞いを変更可能 xerrors パッケージで途中に独自定義したエラー型をラップする方法 ラップするライブラリ Github - sonatard/werror Go で静的解析して Go 1.13 から標準の xerrors とうまく付き合っていく Go 1.13のerrors パッケージ GoDoc - package errors 私はGo 1.13のerrorsパッケージを解説する記事は現在執筆していません xerrorsの移行手順 xerrorsへの移行手順 Go 1.12

私がWebアプリケーションを実装するうえのエラー設計をどのようにアーキテクチャの中で実現しているかを紹介します。 以下の方針で設計しています。 アプリケーション層にレベルを付与したエラーを定義する アプリケーション層では、定義したエラーに変換する ミドルウェアは全アプリケーション共通にする 以下、サンプルコードです。 サンプルのため省略していますが、実際にはパッケージ分割やファイル分割をしています。 package main import ( "fmt" "os" "golang.org/x/xerrors" ) var ErrUnknown = &ApplicationError{ code: 100, level: "Error", msg: "unknown", } var ErrUserNotFound = &ApplicationError{ code: 101, level:

多くの方が違和感を持つと同時に Wrap メソッドではいけないのか？と疑問を持ったと思います。 この記事ではその理由をProposal: Go 2 Error Inspectionから考察します。 : %w の理由 We included a Frame in the errors returned by errors.New and fmt.Errorf so that existing Go programs could reap the benefits of location information. We benchmarked the slowdown from fetching stack information and felt that it was tolerable. We changed the behavior of fmt.Errorf for the same

先日 xerrors パッケージがリリースされました。 このパッケージは、Proposal: Go 2 Error Inspection で提案されているものをGo1向けに外部ライブラリとして試験的に実装したものです。 Goの標準ライブラリではありませんが、Go公式がメンテナンスをしています。 このパッケージができた背景は、今まで多くのGoエンジニアは下位層のエラーの情報を伝播させるために pkg/errors パッケージ などの外部ライブラリを利用していました。この手法が開発者の間で普及したため標準ライブラリで正式に検討を始めることとなりました。 2019/9/4更新 Go 1.13では %w でのラップや Is メソッド、 As メソッドは正式に導入されました。 しかし%+w や %+v によるスタックトレースの表示の採用は見送られました。 スタックトレースの表示が必要な場合はxerr

はじめに Goの良いところは、最低限の文法を知っていればコードを上から順番に読むことで詳細を容易に理解できることです。 文法の中にシンタックスシュガーや特別な省略が許されていないため多様な表現になることはありません。 そのためGoを書ければGoの本体と標準ライブラリを読むことができます。 しかし以下の原因により、これらの利点を守ることが難しくなることがあります。 DSL フレームワーク 抽象化 これらは設計として新たな制約を課すことで品質向上や実装を容易にするためのものです。 またこれらを採用する論理立てた 正しい 理由が存在します。 DSL DSLを提供するツールとして、DIのための wire があります。 GoでDIを実現するためには多くの実装を必要とするため、実装量を減らすためにもDIツールが求められてきました。 これは 正しい です。 しかし一方でDSLはコードを読む人間に言語以上

なぜこれが理想形なのかというと、Circle CI 2.0ではソースコードの変更検知、チェックアウト、コマンド実行、結果通知だけに徹するべきであり、その他の責務については適切な他のツールが担うべきだと考えているためです。 責務を意識して適切にツールを採用していくと、以下のメリットが得られます。 特定のCIツールを過度に学習する必要がなくなる 特定のCIおじさんだけではなく開発者全員がメンテナンスできるようになる CIツールとエンジニアから共通のスクリプトが実行される その結果、スクリプトがメンテされる状況を維持できる 別のCIツールに移行できる ツールの採用 CIで実施する処理は以下になりますが、config.yml には直接書かずに適切なツールで実現します。 ソースコード変更検知 実行環境の準備 実行環境に必要なツールの準備 ソースコードの準備 ビルド、テスト、デプロイ 結果通知 上記の

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

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

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

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに GoはC言語やその後のオブジェクト指向言語における課題をシンプルな手法で解決しており、大変使い勝手の良い言語になっています。 具体的にはC言語と比較すると以下のような点が優れています。 充実した標準ライブラリ コンパイルの容易さ 公式フォーマッター クロスコンパイル、マルチプラットフォーム対応 複数返り値によるerrnoからの脱却 インターフェースによるオブジェクト指向の実現 GC(Garbage Collection) スタックやヒープを意識しないプログラミング 整数仕様の整理 今回はこの中でも紹介されることが少ない整数の仕

はじめに Goは、Go1.5以降C言語による実装がなくなり、ほぼ全てがGoによって書かれています。そのためGoエンジニアは最悪Goのソースコードを読んで問題を解決することができるため、とても生産的な状態にあると言えます。 しかしGoがセルフホスティングだとしてもOSの機能群を呼び出すときには、C言語で実装されているシステムコールを実行しているはずです。では、Goではどのようにシステムコールを実行しているのでしょうか？また、どのようにそれらをビルドしているのでしょうか？ この記事では、上記の疑問をGoのソースとドキュメントから読み解いていきます。 Goとシステムコール 一般のGoプログラマがGoでシステムコールを実行するには、syscallパッケージ、golang.org/x/sys/パッケージを利用します。1 関数一覧には見覚えるのあるシステムコールと同様の名前の関数が並んでいます。これら

$ go build -x # 作業用のディレクトリを作成 WORK=/var/folders/4z/yzprxc9n5sx7gly7ybrynkl80000gn/T/go-build482602531 mkdir -p $WORK/github.com/sonatard/buildtest/_obj/ mkdir -p $WORK/github.com/sonatard/buildtest/_obj/exe/ cd /Users/ken/src/github.com/sonatard/buildtest # コンパイル /usr/local/Cellar/go/1.7.3/libexec/pkg/tool/darwin_amd64/compile -o $WORK/github.com/sonatard/buildtest.a -trimpath $WORK -p main -compl

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