DevFest18 session6 roomA+B
![Goらしいコードを業務でも書くために](https://cdn-ak-scissors.b.st-hatena.com/image/square/2f302286af7bb98b4e0244e936c7e881a564b05e/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fde01972ad187467aad939a386d7b49e3%2Fslide_0.jpg%3F10676850)
社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま
「2017/9/9 Scala関西Summit 2017」、「2017/10/21 関ジャバ'17 10月度」 、「2018/3/18 Scala Matsuri 2018」でお話した、実践ScalaでDDD の発表資料です。 (English version -> https://speakerdeck.com/crossroad0201/practice-ddd-with-scala-en ) サンプルコードもあわせて参照してください。 https://github.com/crossroad0201/ddd-on-scala 目次 1.DDDとは - DDD - DDDのコンポーネント 2.ScalaとDDD 3.Scala実装スタイル 4.アーキテクチャ - レイヤ構成 - エラー処理 5.コンポーネントの実装 - アプリケーションサービス - エンティティ - バリューオブジェク
書き込みと読み込みのどちらに力を入れているかは、ストレージエンジンによって異なります。たとえば昔ながらのリレーショナルデータベースは、外部キーなどの制約を使ってデータの整合性をうまく制御できるようになっています。一方でNoSQLデータベースは、スループットとスケーラビリティを確保するために、そういった組み込みのガードレールをはずしてしまいました。データ層においても、どちらか一方に特化した最適化をすることがあります。たとえば、あらかじめ計算済みの値を保持しておけば、「一日あたりのサイト訪問者数」などの読み込み操作を効率よく行えるでしょう。ストレージソリューションのメーカーはどこも、「うちのプロダクトならあらゆるニーズを満たせます」などと自社製品の機能を自慢します。しかし実は、昔ながらのCRUDモデルに沿ってストレージエンジンを選んでデータ層を設計した時点で、さまざまな関心事の間で何らかの妥協
「Clean Architectureはファイル数が多くてめんどくさい」という話がよく上がるなと思ったので、簡易化するとしたらどこを省略するべきかなというのを考えてサンプルを作ってみました。 Github - a-beco/SimpleCleanArchitecture 結論としては、Interface Adapterを省略する形で書いています。小~中規模ぐらいのアプリつくるならこれぐらいで書いてもワークするんじゃないかなと思っています。 この記事では、今一度Clean Architectureとは、という話と、勘違いされがちなポイントをまとめつつ、今回のサンプルの構成について簡単に説明します。 Clean Architectureとは 以前、Clean Architectureについての記事を書きました。Clean Architectureとはなんぞやという話についてはそちらのほうが詳し
先日、サイバーエージェントさんの「身に着けた技術をいかに捨てられるか。エンジニア歴39年、今でもエンジニアで居続ける理由。」という記事が大変話題になりました。 プログラミングやテクノロジーが大好きでWeb業界で働いているエンジニアの方の多くは、「可能であれば50代以降も現場で"手を動かすエンジニア"として働きたい」と考えてらっしゃると思いますが、平松さんのような方はかなり例外的で、Web業界で多数の現場を経験してきた私でも、50代以上の現役エンジニアの方とご一緒にお仕事をさせて頂いた経験は残念ながら一度もありません。 私は現在、雑食系エンジニアTVというYoutubeチャンネルで、Web系エンジニアのキャリアに関する情報を色々と発信させて頂いているのですが、視聴者の方から「Web系エンジニアの50代以降のキャリア」に関してご質問頂いても、完全に未知の領域になる&ロールモデルとなる方があまり
(images: github.com/egonelbre/gophers) こんにちは。 データエンジニアリンググループ(CETチーム)の寺下です。 自分の所属するCETチームでは今まで主にScala、Pythonなどを使ってAPIや基盤を実装してきましたが、最近では徐々にGoによる実装も増えてきており、GAE/GKE上で本番運用を行っています。 本記事ではGoのプロダクトにおいてDDDライクなpackage構成で実装する際の注意点や、汎用的に通用するであろう実装のTipsについて書いていきます。 本記事で紹介する例がベストプラクティスだというわけではありませんので、あくまで実装の一例程度に捉えて頂けると幸いです。 Goのアーキテクチャ Goは言語仕様がシンプルかつフォーマッタが強力なため、syntaxレベルでは開発者によってコードの品質がブレにくいというメリットがあります。 しかしなが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く