Postmanの日本市場におけるDevRel (的) 活動 / Postman's DevRelish activities in Japan

All slide content and descriptions are owned by their creators.
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブ
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (130件) を見る ドメイン駆動設計読み終った。ドメインを中心に据えてソフトウェアを設計するための方法を教えてくれる本だった。設計の話なので、抽象度が高く、なかなか読み辛いけど、良い話がたくさんでてくる。この本で例にでてくるソフトウェアが経理システムだとか貨物の配送システムなどのエンタープライズよりだったので、はじめは自分のようなWebエンジニアとっては参考にしにくいかと思っていたのだけど、まったくそういうことはなく、たいへん参考になった。 ドメイン駆動設計でいうドメインとはソフトウェアが
ドメイン駆動設計というのはソフトウェア工学のおしゃれな本で,Kindleで買えたので読んだ.ドメインを軸に戦略的に設計しましょうという本.2週間くらいで読めて良い体験できてよかった. ソフトウェアを,ユーザーインタフェース,アプリケーション,ドメイン,インフラストラクチャという4つの層に分けて,一番重要なのがドメイン層で,ドメイン層にアプリケーションが存在し得る理由がある.銀行システムだったら,口座とか利子みたなやつがドメイン層で,口座がよくできてると銀行としてうまくいく.ATMのタッチパネルというのはユーザーインタフェースで,どんなにATM押しやすくても,ドメイン層に,口座という概念がなくて,ただのハッシュだったりすると,銀行を運営して金を儲けるとか,新たな金融商品とか作るのが困難になる.インフラ層は永続化とかするのだけど,インフラ層がいかによくても,意味ないデータを保存していては銀行倒
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く