どうやら本当のデスマーチを教える時が来たようですね - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この業界、デスマーチという用語が安易に使われすぎていると私は感じています。自虐的な表現が好きな日本で、この言葉はとてもウケが良かったのでしょう、他の IT 系ことわざに比べて極端に有名です。 が、そのために誤用も増えてきました。たんに自分の仕事がきつい状態になることを「デスマってる」と表現する人がいますが、本当のデスマーチはそんなものではありません。まず、「マーチ」である以上、個人の問題ではないというのが最重要点です。 デスマーチとは組織の病です。ソフトウェア開発プロジェクトを計画するトップが未熟だと、その素人見積のせいで、見えていない
スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
このような要求があった場合、一般的なエンジニアはメールアドレスと電話番号を持つクラスを定義し、どちらもオプショナルな値（必須ではない）にするような設計をするかと思います。そして、作成時・追加時・編集時にどちらもなければエラーにするというバリデーションを実装することでしょう。つまり、要求をそのままに実装に落としていくという意味です。要求自体はかなり具体的に書いてありますから、そのまま実装に落とすこと自体が悪いとは言い難いでしょう。 一方、なぜメールアドレスと電話番号の2つを利用アカウントが持っているのかという「意図」をよりはっきりと記述してもらった次のような要求を見てみましょう。 要求を発する側の意図としては、ただ単にメールアドレスや電話番号が独立して欲しいと考えていたのではなくて、利用アカウントごとに1つは「連絡先」が欲しい。ひいては、何らかの手段で連絡できるといいなと考えていたことがわか
ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は クラウドワークスアドベントカレンダー2019 12日目の記事です。 概要 こんにちは、怒り駆動リファクタリングを生業としている @MinoDriven です。 弊社リファクタリング専門チーム「バグハンター」で現在実施中のリファクタリング設計について紹介致します。 ドメイン駆動設計 を用い、Railsレガシーコードに対しViewとControllerを ActiveRecord非依存 に変更する設計です。 状況 弊社ブログの過去エントリにあるように、弊社サービスcrowdworks.jpはサービスインから8年経過し、 30万行
スタートアップである弊社が全員ほぼ未経験でRuby on RailsをScalaに移行した理由、その効果と苦労点 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事を書くに至った経緯 僕が代表をしている株式会社KOSKAでは製造業の原価管理をIoTで自動化するGenkanというサービスを提供しております。 そんな弊社では半年前、バックエンドをRuby on RailsからScalaに移行したのですが、その効果が思ったよりだいぶ大きく、いずれこの効果を共有したいなーと思っていました。 弊社ではスタートアップで全員ほぼ未経験状態のScalaを採用するという挑戦をした結果、「Scalaを書きたい」というレベルの高い人材をかなりの確率で捕まえられるようになり、開発がものすごい加速した上に堅牢になっ
DDDの頻出用語をなんとなく理解する - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに DDDの勉強を始めてみたものの初見の用語がバンバン出てきて心が折れそうになったので、雑にまとめてみました。 「雑だけどなんとなく分かる」を優先しているので一部正確ではない表現があるかもですがご容赦ください。 （航空監視システムの話がちょくちょく出ているのはDDD Quicklyの例でよく使われていたためです。） 全体的な話 ドメイン システム化しようとしている現実世界の万物です。 例えば航空監視システムを作ろうとしているなら、航空監視に必要な人・モノ・情報・業務・etc...です。 当然これら全てをシステムに落とし込むことはで
Software Architecture - DDD と アーキテクチャ にまつわるエトセトラ - Qiita
要約 / inb4 tl;dr DDD（ドメイン駆動設計）について調べ始めたら、解説記事でお腹いっぱいになった。 更に、一緒に語られるアーキテクチャも整理したい欲が出てきた。 Layered Architecture Layered Architecture with DIP (Dependency inversion principle) Hexagonal Architecture Onion Architecture Clean Architecture こういった経緯で、元になった書籍や記事をまとめてみた。 ちょっとしたまとめも書いた はじめに 『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』 を読んで DDD入門をしてみて、ボトムアップで作り上げるときの アーキテクチャ に興味が湧き、今後、調べていくに当たって最初に見るべきであろう情報をまとめてみました。
混在したモデリングパラダイムの中で学ぶ重要なこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? このエントリーは、 「ドメイン駆動設計 #1 Advent Calendar 2018」の2４日目の記事です。 23日目は、@smdmts さんの「ユビキタス言語と境界付けられたコンテキストを構築する目的とは」でした。 DDD本で触れられている、モデリングパラダイムについて考えを晒します。 モデリングパラダイム まずはモデリングパラダイムについて考えましょう。 目的 「モデリングパラダイム」という言葉をどういう意味を持つのでしょうか。それは、以下の二つの単語で構成されます。 モデリング 広義の意味での模型（モデル）を組み立てる事を言う。
Reduxにドメイン層を導入する - Qiita
【2018/6/18更新】immutable.js を利用せずに、当エントリー同等以上の開発が可能な、FP・型推論の強いモジュールを公開しました。https://qiita.com/Takepepe/items/a79e767b38981c910c3f ドメインモデルの需要 フロントエンドフレームワークでプロダクトを作り込んでいくと、ビジネスロジックが view に介入しすぎてしまうことが少なからずあります。下記の様なビジネスロジックが散在しているコードに、スケール耐性があるとは思えません。リリース当時は単純だったものが、複雑に変化していくケースは往々にしてあります。 function TodoItems (props) { const { todos, updateTodo, deleteTodo } = props const items = todos.map(item , i) =
実装 - Hexagonal Redux - - Qiita
Reduxのヘキサゴナルアーキテクチャ Reduxの様なイベント駆動アーキテクチャでDDDの恩恵を受けるため、ヘキサゴナルアーキテクチャを採用するモデリングの考察です。疎結合なドメインモデル同士は、時に外部ドメインで扱う横断的関心事を参照する必要が出てきます。 Redux は SingleStore のため、全部入りのエンタープライズモデルと捉えられがちですが、それを構成する Reducer と対の Model が、マルチドメインを構成する単体のドメインモデルだと捉えています。先日投稿したモジュールの構成で、ヘキサゴナルアーキテクチャを採用する準備は出来ています。用語のマッピングは以下の通りです。 DomainModel = immutable.Record DomainEvent = ReduxAction Port(in) = ReduxReducer Port(out) = Redu
UXD and DDD (UX デザインとドメイン駆動設計) - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに NewsPicks のソフトウェアエンジニアの三浦です。NewsPicks アカデミア というプロダクトの開発チームリーダーをやっています。NewsPicks Advent Calendar 2018 の12日目を担当します。 今回は、ソフトウェアエンジニア視点でのプロダクトづくりについて、 UX デザイン(以下 UXD)とドメイン駆動設計（以下DDD）を中心に書いてみようと思います。 なぜ UXD と DDD を同時に論じようと思ったのか 結論から先に書くと UXD と DDD は親和性が高いのではないか？と考えたからです。
アプリケーションサービスの凝集度を高めたい - Qiita
ドメイン駆動設計 #1 Advent Calendar 2018の 12 日目担当記事です。 11 日目 は @YasuhiroKimesawa さんのドメイン駆動設計における２つの『不変』です。 13 日目は @dskst さんのDDDで学ぶAPI設計の勘所です。 数年前 IDDD のソースを読んでいたときに考えていたことを言語化してみました。 戦術的設計に関する記事になります。よろしければお付き合いください。 はじめに アプリケーションサービスをご存知でしょうか。 まず大前提としてアプリケーションサービスの知識がないと、この記事は全く意味がないのでアプリケーションサービスについての簡単な解説をします。 既にご存知の方はこの章は読み飛ばして構いません。 アプリケーションサービスはエンティティや値オブジェクトなどのドメインオブジェクトを協調させて処理を行う、スクリプトのような振る舞いを持つ
ドメインオブジェクトを中心としたClean Architecture のためのレイヤー構成 - Qiita
ドメインオブジェクトを中心としたClean Architectureは、どういうレイヤー構成にするとよいか、簡単にまとめてみた。 イメージ たぶん、こんな感じになるはず。通常は円状に表現するが、わかりにくいので層状に書いてみた。 レイヤー構成 赤い部分の層は、直接依存の方向が上から下です。グレー部分の層は、契約だけが定義された独立した層で、ユースケース層やインターフェイス層から依存できるものとします。 インターフェイス（アダプタ）層 内外とのデータ形式の変換が主な役割 コントローラ、プレゼンター（内部から外部へデータ形式を変換する責務）,ゲートウェイ(外部と通信する責務。DBやRPC) ユースケース層 アプリーケーション層ともいう アプリケーション固有のビジネスルールをカプセル化する ドメイン層 Clean Architecture本では、中心にはエンティティとだけ書かれているが、DDDで
役割駆動設計で巨大クラスを爆殺する - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、ドメイン駆動設計を基本思想とする「役割駆動設計」を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 小さくシンプルな構造に落とし込み、堅牢で変更容易性の高い設計へ昇華させる。 例１：筆者をモデリング 分かりやすくなるよう、まず私を例にモデリングしてみます。私は以下のような特徴があります。 IT企業
ドメインオブジェクトの責務について - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 設計するとき、「このオブジェクトの責務は何だろうか？」とか「この責務に名前をつけるなら何か？」とか、責務について考えることがよくあります。そもそもその責務とは何か、という根源的な疑問について再確認すると共に、ドメイン駆動設計の観点からドメインオブジェクトの責務についても考えてみたいと思います。 責務とは 困ったときの古典引用。もう絶版になった、オブジェクトデザインという、書籍を紐解いてみましょう。DDDからの引用が多い書籍で、DDDの設計スタイルは、この書籍で紹介する「責務駆動設計(responsibillity-driven desi
「実践ドメイン駆動設計」を読んだので、実際にDDDで設計して作ってみた！ - Qiita
こんにちは、クラウドワークスの新規事業のエンジニアとして仕事をしている高梨です！ 最近、「実践ドメイン駆動設計」という本を読みました！ 500ページ近くもある技術書で、なかなか量は多かったのですが、DDDがどんなものなのか一通り大枠を掴めた気がします。 ただ読み終わった後にこんな疑念や不安をいだきました。 「たしかにかなり面白そうだけど、実際にやるとどれだけ工数かかるんだろう...？」 「設計の話は全然出てこなかったけど、DDDで作るとなるといったい何から始めればいいんだ？」 「戦術についての知識はついたけど、実際に書こうとしたらできなそうだな...」 そこで、そういった疑念や不安を解決するために、実際にDDDでサンプルプロダクトを作ってみようと思ったわけです。 実際に作ってみるのが、結局一番理解が進みますしね。 今回は、そのプロダクトがリリースされるまでの過程や感想を、作成した設計書やソ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
0からScalaを本番導入して感じたこと・考えたこと - Qiita