「システム設計の謎を解く」を読みながら設計について考える - 勘と経験と読経
書籍モニターキャンペーンに当選したので、今月末に発売予定の書籍「システム設計の謎を解く」を読み始めた。まだ全部は読み終わっていないのだけれども、設計に関して考えた事について。 システム設計の謎を解く 強いSEになるための機能設計と入出力設計の極意 作者:高安 厚思SBクリエイティブAmazon良書の予感(いま3章まで読んだところ)。 ソフトウェアの設計を「考える」 最近の風潮では（あくまで個人的感覚だが）なんというか「設計」は軽視されがちだ。 アジャイル開発のメジャー化に伴って、プログラミングを中心とした方法論やプラクティスは割りと注目されている。 SIerを中心に以前としてあるプロジェクトマネジメントや、要求管理は引き続き注目されている(ような気がする)。 他に、運用関連やテスト(プロセス)関連も割りと話を聞くような。 本来はソフトウェア開発のど真ん中にあるべき「設計」に関する話題で盛り
「システム設計の謎を解く」の感想 - 勘と経験と読経
書籍モニターキャンペーンに当選してプレゼントいただいた書籍「システム設計の謎を解く 強いSEになるための機能設計と入出力設計の極意」を読了したのでその感想など。自分にとっては恐ろしいほどに有用な本だった。ただひたすらにソフトウェア開発の基本設計について考える本。 以前に書いた記事はこちら 「システム設計の謎を解く」を読みながら設計について考える - 勘と経験と読経 アジャイルフリーでテクノロジーフリーな基本設計の本 本書は一言で言うとそんな感じ。 要件定義の領域は扱っていない（ただし、基本設計の前にやるべき事は整理されている） アプリの基本設計が中心でアーキテクチャ設計は軽く触れる程度 詳細設計についても範囲外 オブジェクト指向設計については軽く触れる程度 アジャイル開発も触れる程度 この割切り（？）は顧客の立場に立って考えるととても実践的だと思う。 顧客の立場からすると アーキテクチャの
WEB+DB PRESS Vol.74
2013年4月24日紙版発売 2014年12月23日電子版発売 B5判／184ページ 定価1,628円（本体1,480円＋税10%） ISBN 978-4-7741-5607-1 ただいま弊社在庫はございません。 Amazon 楽天ブックス ヨドバシ.com Fujisan（定期購読のみ） 電子版 Gihyo Digital Publishing honto 本書のサポートページサンプルファイルのダウンロードや正誤表など 特集1 [Web開発1年目に身につけたい]良い設計の基礎知識 ～変化に強い構造・読みやすいコード・適切な分割～ 本特集はWebサービスを開発する際に必要となる，設計手法についてまとめています。今ではあらゆる言語，フレームワーク，データベースが登場し，以前より増して効率的な開発が行える状況になっています。しかし，実装の前段階となる設計がきちんと行われていないと，実装に手間取
分散オブジェクト・アーキテクチャ／ドメイン指向アーキテクチャ - 石橋秀仁(zerobase)書き散らす
これから述べる分散オブジェクト・アーキテクチャに近いフレームワークやアプリケーションの実装がすでにあれば教えて頂けると助かります。 背景：ゼロベースの管理会計システムを開発するよ。 （凡例：追記と削除） 目的 ドメイン駆動設計(DDD)を原理的に突き詰めたアーキテクチャによって、オブジェクト指向プログラミングの作業から、インフラストラクチャ層に関する配慮がほとんど不要になる。SQLもデータスキーマ設計も不要になる。 といっても、Ruby on RailsのActiveRecord的な話ではないので、誤解なきよう。むしろ正反対。リレーショナル・データベースを使わない。 ドメインのオブジェクトをシンプルに書けばシステムが実現するようになる。一言で言えば、「GOOS/DDD原理主義者のためのフレームワークが欲しい」という話。 ウェブ・アプリケーションの三層アーキテクチャ再考 ウェブ・アプリケーシ
ドメイン駆動設計：４つのアンチパターン | システム設計日記
６月２３日（土）午後、大阪で、ドメイン駆動設計について、しゃべる予定。 第47回 SEA関西プロセス分科会のご案内 紹介の紹介の紹介、みたいな不思議なつながりで、講演の依頼があった。 「ドメイン駆動設計」を監訳された今関さんも参加いただける。 土曜の午後なので、時間が多め。 一方的にしゃべって終わりではなく、今関さんも交え参加者で、いろいろ話す時間を一時間以上とってもらいました（さらに懇親会もゆっくりと）。とても楽しみなイベントです。 ドメイン駆動設計は、訳本がでてから、あちこちで勉強会や読書会が開かれているようだし、ドメイン駆動設計に興味持ったり、現場で取り組む人が、すごく増えた気がしている。 ネットで流れる情報も「ドメイン駆動ってなんぞや？」的なものだけでなく「私は、こう理解している、やっている」的なものが多くなったんじゃないかなあ。 訳本の威力は絶大。 さて、講演の準備は、いつものよ
ドメイン駆動設計は設計のアジャイル化～オブジェクト指向設計の先祖返り - プログラマの思索
エリック・エヴァンスのドメイン駆動設計の本を一通り読んでみて、何かすっきりしない感想を持っていた。 @sakaba37さんや@jp_watanabeさんと議論して、すっきりしない原因がようやく分かったのでメモ。 ラフなメモ書き。 【元ネタ】 ドメイン駆動設計: プログラマの思索 ドメイン駆動設計よりもパターン本が好き: プログラマの思索 ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング: プログラマの思索 DOAとOOAの違い: プログラマの思索 Agile開発に足りないもの～モデリング技術: プログラマの思索 ドメイン駆動設計の本の違和感は二つある。 一つは、分析と設計を区別せず、設計中心の技法ばかり説明していること。 もう一つは、過去のオブジェクト指向設計との違いがはっきり理解できていなかったこと。 前者は、「ドメイン駆動設計」というタイトル通り「
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
[ 技術講座 ] Domain-Driven Designのエッセンス 第2回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第2回 DDDの基礎と実践 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 本連載は、全3回の予定でEric Evansの書籍『Domain-Driven Design』（以降DDD）を紹介しています。前回はDDDの概要を説明し、第I部「Putting the Domain Model to Work」からDDDの基本原則となる3つのパターンを紹介しました。今回は続く第II部と第III部から、（アンチパターンを1つ含む）16のDDDパタ
ドメイン駆動設計・基盤編・ドメイン駆動設計の「Why」 - Strategic Choice
ドメイン駆動設計の定義をうけ、「なぜドメイン駆動設計が必要なのか」「なぜドメイン駆動設計が有用なのか」を考えます。なぜ、「ドメインモデルをすべての中心に据える」のか？ソフトウェアがドメインから離れてしまったら、そのソフトウェアは、ドメインの問題を解決することができません。そもそもの存在意義がなくなってしまいます。それを避けるため、ドメインモデルの探求に全力を尽くし、出来上がったドメインモデルからすべてを駆動していきます。そうすることで、ドメインを反映した、より価値の高いアプリケーションにすることができます。なぜ、「ドメインモデリングを反復する」のか？1回きりの開発で完璧なドメインモデルは設計できません。優れたモデルは、何度かアプリケーションのリリースを繰り返す中でようやく得られるものです。その都度、ドメインの知識を深めながら、モデリングを反復して、モデルを「深」化させていきます。なぜ、「ド
Smart UI が優れている？ | システム設計日記
Domain-Driven Design (DDD) で、アンチパターンとして取り上げられている Smart UI 。 ある文脈( context ) では、Smart UI はとても優れている。（と、エバンスも書いている） 実際、私たちが、取り組んだ５年前の開発プロジェクトでは、徹底して、Smart UI でがんばった。 プロジェクトの背景 ・短期間に既存のアプリを作り変えたかった ・中核メンバーは、寄せ集め。（ 設計や実装について、経験や考え方が見事にばらばら ) ・多数の作業者は、一年目のジュニアたち ・既存システムのソースコードは、ない。 Visual Studio で、画面量産 既存システムがあるわけだから、とりあえず、 ・画面の一覧、すべての画面のＨＴＭＬ ・テーブル一覧、テーブル設計と実データ は、そろっている。 ４００画面くらいをメンバー１０人に割り振って、ひとりあたり、４
DDDにおいてRDBMSとのインピーダンスミスマッチをどう扱うべきか？
Ryo Asai @ryoasai74 なるほど。P157「一般的に言えることだが、使っているフレームワークとは争わないこと。フレームワークと対立してしまった時には、ドメイン駆動設計の基本を保ちながら、詳細は捨て去る方法を模索すること。」#DDDjp 2011-04-30 20:20:19 Ryo Asai @ryoasai74 P160「データベースをオブジェクトの格納先として見る場合には、マッピングツールの能力に関わらず、データモデルとオブジェクトモデルをかけ離れたものにしてはならない。」これは読み落としてはならないことですね。モデルと実装を結びつけ、無駄な間接層による複雑さを避けるべき。#DDDjp 2011-04-30 21:01:35
ドメイン駆動設計・俯瞰編 - Strategic Choice
書籍「エリック・エヴァンスのドメイン駆動設計」にある全パターンを、３枚の俯瞰図にまとめます。ボリューミーなこの本を攻略するのに、この本自身にある「大規模な構造（第16章）」という戦略に倣おうと考えたからです。巨大なシステムに包括的な原則がなく、そのせいで各要素を解釈する際に、設計全体にまたがるパターンにおいてどのような役割を果たすかという観点から考えることができなければ、開発者は「木を見て森を見ず」になってしまう。全体の詳細を徹底的に調べなくても、全体の中で個々の部分が果たす役割を理解できる必要があるのだ。「大規模な構造」は、システムをおおよその構造から議論し、理解できるようにするための言語である。第16章 大規模な構造 P447-448「パターン」の仔細を見る前に、各々の「コンテキスト」の中での「立ち位置」をわかっておいたほうが、理解が「速い」し「深まる」と思います。まず「全体における部
Smart UI について、だらだらと - みねこあ
昨年のエントリー、 DDDについて、だらだらと からのびのびになってしまいました、 Smart UI アンチパターンについて。 Smart UI アンチパターンは コの業界で非常に目にするパターンで、また、素人が素人のままで仕事が出来てしまう パターンなのですが、その是非を論じる前に、まずはどういうものかを整理したいところです。 一言で言えば、「Smart UI、アンタ良い者なん？悪者なん？」 * * * DDD の Smart UI “Anti-Pattern” を読んでいると、これは本当にアンチパターンなのかとも思えてきます。 Advantages Productivity is high and immediate for simple applications. シンプルなアプリを作る上では生産性は超高いし、出来るのも早いよ！ Less capable developers can
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: エリック・エヴァンスのドメイン駆動設計: ソフトウェアの核心にある複雑さに立ち向かう: エリックエヴァンス (著), 和智右桂 (翻訳), 牧野祐子 (翻訳): 本