混乱しがちなサービスという概念について - かとじゅんの技術日誌
社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま
scala-on-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.コンポーネントの実装 - アプリケーションサービス - エンティティ - バリューオブジェク
[iOS] Clean Architectureをシンプルに - Qiita
「Clean Architectureはファイル数が多くてめんどくさい」という話がよく上がるなと思ったので、簡易化するとしたらどこを省略するべきかなというのを考えてサンプルを作ってみました。 Github - a-beco/SimpleCleanArchitecture 結論としては、Interface Adapterを省略する形で書いています。小~中規模ぐらいのアプリつくるならこれぐらいで書いてもワークするんじゃないかなと思っています。 この記事では、今一度Clean Architectureとは、という話と、勘違いされがちなポイントをまとめつつ、今回のサンプルの構成について簡単に説明します。 Clean Architectureとは 以前、Clean Architectureについての記事を書きました。Clean Architectureとはなんぞやという話についてはそちらのほうが詳し
![[iOS] Clean Architectureをシンプルに - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/e9c054377c0303c1139a598e142028042d3ddb63/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCaU9TJTVEJTIwQ2xlYW4lMjBBcmNoaXRlY3R1cmUlRTMlODIlOTIlRTMlODIlQjclRTMlODMlQjMlRTMlODMlOTclRTMlODMlQUIlRTMlODElQUImdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTU3Yzk0ODI3MDM4YzRiM2ZmNGUyZTEzNDM2YzgyMTRl%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwYS1iZWNvJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1hNjI4MjRjMDE3MmY0NjcxNGU1NjYxODZjMjBlODc4MQ%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D3ba432083f30d4bcd8254caf75541738)
Goのpackage構成と開発のベタープラクティス
(images: github.com/egonelbre/gophers) こんにちは。 データエンジニアリンググループ（CETチーム）の寺下です。 自分の所属するCETチームでは今まで主にScala、Pythonなどを使ってAPIや基盤を実装してきましたが、最近では徐々にGoによる実装も増えてきており、GAE/GKE上で本番運用を行っています。 本記事ではGoのプロダクトにおいてDDDライクなpackage構成で実装する際の注意点や、汎用的に通用するであろう実装のTipsについて書いていきます。 本記事で紹介する例がベストプラクティスだというわけではありませんので、あくまで実装の一例程度に捉えて頂けると幸いです。 Goのアーキテクチャ Goは言語仕様がシンプルかつフォーマッタが強力なため、syntaxレベルでは開発者によってコードの品質がブレにくいというメリットがあります。 しかしなが
ytake.blog | laravelアーキテクチャ再考と中規模以上のノウハウ(年末特大号)
laravelアーキテクチャ再考と中規模以上のノウハウ(年末特大号) Posted: 2014-12-31 02:02 | laravel PHP全般 年末なので、今年一年laravelを個人規模からそこそこ大規模まで利用したノウハウと、 個人的なポイント等を紹介したいと思います 若干主観もありますが、実際に使った時のものを混ぜて紹介します 実務で使う方や、企業で導入しようと思ってる方にも参考になる様に頑張ります 新原さんの自分流 Laravel 4 アプリケーションアーキテクチャ も是非参考にしてみてください 規模による考え方の違い まずはlaravelはそもそも何向きなのかという事ですが、 開発規模は実際のところは問いません 高速なレスポンス等が要求される場合は、ある程度の規模でしたらPhalconがオススメですが、 お気に入りのフレームワークでしたら何でもいいでしょう！ って事にした
Laravel で Request, UseCase, Resource を使いコントロールフローをシンプルにする - Qiita
この記事について 「Clean Architecture」（Robert C. Martin 著）に触発されて、ユースケースパターンを試してみたので、その記録です。 本書では UseCaseInteractor という名前になっていますが、本記事のサンプルでは UseCase としています。 あくまでも触発されただけなので、Clean Architecture に完全に沿ってるわけではないので、その点だけご注意ください、詳しくは書籍をお読みいただければ、と思います。 環境 PHP: 7.1.16 Laravel: 5.5.42 サンプルコード 「Clearn Architecture」にある Interactor についての記述を引用します。 ウェブサーバーは、ユーザーからの入力データを受け取り、左上のControllerに渡す。ControllerはプレインオールドなJavaオブジェクト
中小規模のOSSにおけるバージョニング戦略について | おそらくはそれさえも平凡な日々
TL;DR 互換は壊すな！…なるべく メインラインに手を入れ続けることが最優先 複数バージョンをきちんとメンテしようなどとはゆめゆめ思うべからず 本編 OSSのバージョニングについての個人的な意識について書きます。「中小規模」というのは、個人の趣味だったり、企業でやっていたりしてもそんなにリソースをかけられない場合くらいの規模感、つまり僕自身がメンテナンスに関わっているようなソフトウェアの規模感でもあります。とは言え、リソースが十分なプロジェクトなどほとんど無いと言えるので、多くの場合に当てはまるでしょう。 互換は壊すな！…なるべく そもそも互換は壊すなよ、と言う話。互換は壊さないほうがいい。これに異を唱える人はいないでしょう。 「互換を壊したらメジャーバージョンを上げればいい」ではなくて「絶対に壊さない」くらいの意識でAPI設計をする。それくらい慎重に設計したとしても互換を壊さないといけ
日時のフォーマット（ISO 8601） - Qiita
ISO 8601 の中でも書き方は色々とありますが 年月日と時間 タイムゾーンに対応 年は4桁（2桁では年が確定できない） 単位は秒まで（ミリ秒も可能だが桁数が定まっていないため） という条件から利用しやすいフォーマットです。 利用実例 YouTube Data API https://developers.google.com/youtube/v3/docs/videos?hl=ja AWS (Amazon Web Services) の一部のサービス Kintone https://cybozudev.zendesk.com/hc/ja/articles/201941754-REST-API%E3%81%AE%E5%85%B1%E9%80%9A%E4%BB%95%E6%A7%98#step6 Register as a new user and use Qiita more conve
Inversion of Control コンテナと Dependency Injection パターン
以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 本記事では、このパタ
Clean ArchitectureでAPI Serverを構築してみる - Qiita
この記事では、アーキテクチャを採用する理由、次にClean Architectureの概要、最後にアプリケーションの構築をしていきます。 この後詳しく見ていきますが、Clean architectureの概念は比較的シンプルでわかりやすいものだと思います。しかし実際コードに落とし込んだ時、これってどう実装すればいいのかな？と迷うことがあったので、自分の理解も深めるために実際にAPI Serverを構築していきたいと思います。 また、サーバーサイドでの採用事例をあまりみないので誰かの参考になればいいかなと思います。 サンプルコードは、Go言語です。 アーキテクチャを採用する理由 アーキテクチャに期待することは、関心の分離です。 関心の分離を正しく行うことで、次のようなメリットがあると思います。 再利用性の高い設計になり生産性が向上する コードの可読性が上がり、メンテナンスが容易になる 変化に
コード設計編: context による縦軸分類とレイヤードアーキテクチャ（新規開発のメモ書きシリーズ3）
流行りの monorepo 風味と DDD 風味？ 今回はコードの設計について書き残します。主に JavaScript 界の話です。Web アプリケーション全体の設計は次回で、今回はコード面の設計に限定して書き留めています。プロダクト全体のアーキテクチャは次の記事で述べる予定ですが大雑把には、メディアっぽいサービスでありつつも SPA + SSR が許容される程度には要件定義の時点でコードの行数がかさむことが約束されたプロダクトです。 今回は大きく分けて下記について述べています ディレクトリ構造 オブジェクトの種類と責務 Flux 的なデータフロー あくまで風味なので今回、専門用語の意味ズレなどは優しくお願いします... このシリーズの他の記事はこちら。 技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選 ビルド設定編: UA に応じた最適な JS バンドルの配信と web
ちいさく始めるレイヤードアーキテクチャ
俺コン Vol.1 / Day.1 Track C で発表した資料になります。 #orecon_ios #kyobashiswift
『現場で役立つシステム設計の原則』は一般的なSI現場で役立つのか？
DDD Alliance!主催の「現場で役立つシステム設計の原則 Night!」での書評LTスライドです。
DIコンテナのインジェクション方法の使い分けについて - 日々常々
DIコンテナを使う時にどのインジェクションを使うかって話です。 たぶん誰かがどこかで同じようなことを書いているだろうけれど、気にせず書くよ。 「他の誰かが書いている」なんてのを書かない理由にしてると何も書けなくなるし。 コンテナ DIコンテナのこと。 コンテナ管理 インスタンスのライフサイクルをコンテナが管理していること。雑に言えば、使う側で new しないってこと。 インジェクション Dependency Injectionのこと。 Short Answer コンストラクタインジェクションを使いましょう。使い分けなくていいです。 3種類のインジェクション インジェクションには3種類ありますね。他あっても知らない。 フィールドインジェクション セッターインジェクション コンストラクタインジェクション フィールドインジェクション 一番よく見るかな。 class Hoge { @Inject
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
なぜDDD初心者はググり出してすぐに心がくじけてしまうのか - Qiita
DDD連載記事 * なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか * ドメイン駆動設計の定義についてEric Evansはなんと言っているのか * モデルでドメイン知識を表現するとは何か * ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か * ドメイン駆動 + オニオンアーキテクチャ概略 背景 直近のプロジェクトでDDDの思想に則ったアーキテクチャで一つリリースまで漕ぎ付けまして、そこに至るまで色々と調べたり試行錯誤をしながら学んだことを書いていこうと思います。 一番にですね、大体のDDDに興味を持った人がいうのが ということなんですよね。 DDDは思想としてすごく面白く、とても実用性なものなのに、なんでこんなにわかりづらいのか、ハードルが高いのか！！ という点について、私なりの解釈を述べたいと思います。 心をくじく要因 Eric Evans本は説明
Rails：Service層を運用して良かったところ、悪かったところ - Qiita
1年前くらいにRailsの設計にDDD(ドメイン駆動設計)のService層を導入し、Modelの肥大化対策をしました。 この記事では、まずどのようなルールでService層が組み込まれているかと、1年間運用してみて良かったところ、悪かったところの感想を書きます。 [2018/05追記] 最近ではサービス層の導入は賛否両論あるようなので、導入する際は自分のプロジェクトに合っているかどうかを十分にご検討ください！ Service層を導入するきっかけになった問題点 Modelの肥大化 Model間の複雑な依存関係 多数のミドルウェアの導入による複雑さの倍増 これらにより.. メンテナンスやテストがしにくい コードが整理されていないのでとにかく読みづらい Model複雑化の例 <ユーザがECサイトの商品をお気に入り(like)にするメソッドを書く場合> 処理に関連するテーブル my_itemsテ
例外設計、チェック例外の是非 - torutkのブログ
最近、Javaの例外について、特にチェック例外について否定論を見かけることがありました。Kent Beck、Robert C. Martin、Bluce EckelといったJava・オブジェクト指向プログラミングにおいて見識ある著名な人物がこぞって否定論を唱えています。自分的にはいまだ同意できないのですが、これだけの人物が並んで唱えると、ちょっと弱くなってチェック例外って本当に使うのが最善なのか考えてしまいます。 チェック例外について、賛成の立場で議論がないか探してみたところ、よい記事がありました。 http://littletutorials.com/2008/04/27/exceptional-java-thoughts-on-java-exceptions/ から始まる一連の記事で、チェック例外について賛成の立場で例外設計を述べています。また、戻り値と例外についても議論があり、例外設
続々・リトライと冪等性のデザインパターン - あらゆる操作を冪等にする方法 - Blog by Sadayuki Furuhashi
いつも心に冪等性。古橋です。 リトライと冪等性のデザインパターンの完結編です。 だいぶ間が空いてしまいましたが！ 最後に冪等性を実装する汎用的な実装手法についてまとめていきます。 パターン６：操作ログとリクエストIDでUPDATEを冪等にする 同じIDで識別される値がUPDATEされる場合、つまりmutableである値の管理は、一般に冪等に行うのが難しい。 例えば、ユーザーごとに「最後に購入したアイテム」を更新する操作を考えてみると： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE） 2. ユーザーAが最後に購入したアイテムをアイテム2に変更する（UPDATE） この操作に何の対策もなくリトライを実装した場合、後続のUPDATE処理の結果を古い内容で上書きしてしまう可能性がある： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE）→
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - crossroad0201/ddd-on-scala: DDD sample implementation by Scala.
