Finding Laravel Best Practices in 2018 - Speaker DeckLaravelでテストしやすいコードを書く5 / 5 tips of building testable modules in Laravel
混乱しがちなサービスという概念について - かとじゅんの技術日誌
社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま
[iOS] Clean Architectureをシンプルに - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 「Clean Architectureはファイル数が多くてめんどくさい」という話がよく上がるなと思ったので、簡易化するとしたらどこを省略するべきかなというのを考えてサンプルを作ってみました。 Github - a-beco/SimpleCleanArchitecture 結論としては、Interface Adapterを省略する形で書いています。小~中規模ぐらいのアプリつくるならこれぐらいで書いてもワークするんじゃないかなと思っています。 この記事では、今一度Clean Architectureとは、という話と、勘違いされがちなポイント
![[iOS] Clean Architectureをシンプルに - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/504a68ce75d4b8bb39083849eb744e00149d2a19/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGNDA5MjglMkZwcm9maWxlLWltYWdlcyUyRjE1NDYyNzEzNzQ_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmZtPXBuZzMyJnM9YzIzNmFmNGM5NmUxZTk2ZGIzMDUzZDYxOTczMDVmYmE%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253Dd71243f1d08e94ae02feb29aa5372e1b%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCaU9TJTVEJTIwQ2xlYW4lMjBBcmNoaXRlY3R1cmUlRTMlODIlOTIlRTMlODIlQjclRTMlODMlQjMlRTMlODMlOTclRTMlODMlQUIlRTMlODElQUImdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtcGFkPTAmcz1lZDhmMjZiMjQwMjcxNWUxNDdjYzNiNDI3ZDhhMWY1ZA%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBhLWJlY28mdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtcGFkPTAmcz1kMjQ3ZDIxMWViZTY1M2JmODgxZTkzMDViMjIzYjY2Mw%26blend-x%3D242%26blend-y%3D454%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-44K144Kk44OQ44O844Ko44O844K444Kn44Oz44OI%26txt-x%3D242%26txt-y%3D539%26txt-width%3D838%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25231E2121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D28%26s%3D82dcc45b44c26f7beaadd4c2e88a2782)
Goのpackage構成と開発のベタープラクティス | Recruit Tech Blog
(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設計をする。それくらい慎重に設計したとしても互換を壊さないといけ
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は思想としてすごく面白く、とても実用性なものなのに、なんでこんなにわかりづらいのか、ハードルが高いのか！！ という点について、私なりの解釈を述べたいと思います。 心をくじく要因 Eric Evans本は説明が圧倒的に下手。笑 ドメイン駆動設計といえば原著がこの本(以下、原典)なのですが、 エリック・エヴァンスのドメイン駆動設計 この本は本当〜〜〜にわかりづらいです。重要なことは確かに書いてあるんですが、構成がかなりしんどくてまとまりがないのです。一通り実装してからも結局この結論になるので、あの本でわからないのは仕方ないです。笑 まず書籍は実践DDD(以下、IDDD)から入るのが良いと思います。 実践ドメイン駆動設計 ここである程度イメージをもたせてから、興味があったら原点に当たるというのが良いでしょう。 DDDは対象領域が広いが、それが理解されずそれぞれ局所
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/ から始まる一連の記事で、チェック例外について賛成の立場で例外設計を述べています。また、戻り値と例外についても議論があり、例外設
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - crossroad0201/ddd-on-scala: DDD sample implementation by Scala.
scala-on-ddd
日時のフォーマット（ISO 8601） - Qiita
