Smart UI が優れている？ | システム設計日記
Domain-Driven Design (DDD) で、アンチパターンとして取り上げられている Smart UI 。 ある文脈( context ) では、Smart UI はとても優れている。（と、エバンスも書いている） 実際、私たちが、取り組んだ５年前の開発プロジェクトでは、徹底して、Smart UI でがんばった。 プロジェクトの背景 ・短期間に既存のアプリを作り変えたかった ・中核メンバーは、寄せ集め。（ 設計や実装について、経験や考え方が見事にばらばら ) ・多数の作業者は、一年目のジュニアたち ・既存システムのソースコードは、ない。 Visual Studio で、画面量産 既存システムがあるわけだから、とりあえず、 ・画面の一覧、すべての画面のＨＴＭＬ ・テーブル一覧、テーブル設計と実データ は、そろっている。 ４００画面くらいをメンバー１０人に割り振って、ひとりあたり、４
URI 設計の例 ： 郵便番号と住所 | システム設計日記
「住所」を例に、関心事オブジェクトの 識別キー（URI) 設計の例。 日本郵便の郵便番号検索を参考にしてみた。 http://www.post.japanpost.jp/zipcode/ URI のおさらい URI は、ネットワーク上の資源（リソース）を特定するための、 Scheme : "http:" Server : "//www.post.japanpost.jp" Path : "/zipcode/" Query : ?name=value Fragment : #ページ内のブロックのid という構造の識別方式。 「知りたいと思っていること」を、この形式で、どうやって、表現するのが使いやすいサービスだろう？ 日本郵便の実際のサイトの Path と Qeury を参考にしながら、リソース指向アーキテクチャ(ROA)っぽい、URI 設計にチャレンジしてみる。 path 名は、日本語のほ
業務のモデリング 【プロトコルモデリング】 | システム設計日記
採用支援システムを、RDRA(リレーションシップ駆動要件分析） のやり方で、実践中。 RDRA の基本のやり方 １．システムの価値を関係者で共有する ２．システムの外部環境（利用者の使い方や関連システムとの通信要求）を把握する ３．システム境界（画面、ＡＰＩ，メールやファイル転送などの通信）インタフェース定義 ４．システム（ドメインモデル、データモデル、機能モデルなど） の４ステップ。 ウォータフォール（後戻りしない）式ではなく、先に進みながら、前のステップとの整合性を検証し、必要であれば、前のステップに立ち戻って、モデルの改善、を継続的に行う。 私たちの場合は、システム規模が小さく、関係者も少ないので、このまま設計・実装まで、ICONIX プロセスを使ってなだれ込む。 システム価値を明らかにする最初の段階で、主要な概念を洗い出した、概念モデルを作って、それを、そのままドメインクラスの実装
システム設計日記
オブジェクト指向設計の目的は、開発効率をあげ、保守しやすい変更が容易なソフトウェアを作ること。そのために、「クラス」（オブジェクトの型）を基本単位にした「モジュール化」を行い、そのモジュールの再利用性を高める設計を目指す。 ドメイン駆動設計の文脈から、オブジェクト指向が狙った「再利用」の現状を考えてみる。 プレゼンテーション層とデータソース層では「フレームワーク」を使うことで、オブジェクト指向による「部品の再利用」のありがたさを日々実感している。 実行基盤として Spring Boot, プレゼンテーション層の Spring MVC と Thymeleaf、データソース層の MyBatis を使うことで、開発期間を短縮でき、実績のあるフレームワークなので、安定した品質も確保できている。オブジェクト指向が狙った「再利用」が実現されている。 しかし、ドメイン層は、毎回、独自に部品を開発している
ドメイン駆動設計は、III部から始めるのが良いかも | システム設計日記
ここしばらく Domain-Driven Design(DDD) の III部 "Refactoring Toward Deeper Insight" を読み直しながら、自分の頭の中の整理のためにも、いろいろ書いてきた。 現場で、DDD を始めるには、このIII部から、はじめるのがいいんじゃないかと思うようになった。 コードレベルで実践できる "Toward Deeper Insight" とはなっているけど、III部のテーマは、まぎれもなく「リファクタリング」。 実際のコードを、どうやって改善するか、という技術者にとっては、具体的で、わかりやすいテーマ。 エバンスは、 ・リファクタリングにも、いろいろレベルがあるよ ・ファウラーの「リファクタリング」はマイクロ・リファクタリング ・「ドメイン駆動設計」では「ドメインモデルの改善」という視点を追加する というようなことを書いている。 出発点
分析パターン ： これだけは覚えておこう | システム設計日記
DDD 11章 Applying Analysis Patterns （分析パターンの応用）では、例として、ファウラーのアナリシスパターンの６章「在庫管理と会計」をヒントに、モデルを改良する話しが載っている。 エンタープライズアプリケーションでは、「在庫管理（企業資産の管理）」は、いつも重要な関心事だし、事実を記録するときに「会計」の考え方とやり方は、基本中の基本。 でも、正直言って、ソフトウェア技術者がファウラーの「アナリシスパターン」の６章を読んで、「なるほどそうか」と、ピンとくるとは思えません。 もうちょっと、単純な原則があると思っている。 私が、自分で考えるときとか、若手の技術者に説明するときに、よく使っている、単純な分析パターンを４つ紹介したいと思います。 ・記録は不変 ・予実の管理 ・連絡 ・情報の集約 この４つをちゃんとやってくれるソフトウェアは、利用者にとって、役に立つし、
DDDの Entities パターンと Value Objects パターンを理解する | システム設計日記
ドメイン駆動設計の基本が、Entities パターンとValue Objects パターン。 本を読んでも、なぜ、これが基本になっているのか、最初はピンとこなかった。 私はこういうふうに理解した、という話し。 name-value ペア ソフトウェアの世界では、name-value ペアをいろいろ使う。 NAME=値 の形式。 "=" は、タブのこともあれば、":" のこともある。 XML が一般的になる前は、設定ファイルといえば、これ一辺倒だった。 HTTPのリクエストとか、SMTP のメールヘッダーとかもそう。 Amazon の SimpleDB なんかもそうですね。 Java の Map は、 key-value ペアを扱うコレクション。これも、name-value ペアといっしょですね。 こういう情報の扱い方は、なじみが深いし、なにも考えずに使っていますよね。 これが、そのまま、
システム設計日記
テスト駆動開発 和田卓人(t-wada)さんによる『テスト駆動開発』の新訳版が出版されました。 オブジェクト指向でソフトウェアを開発するのであれば、この本とマーチンファウラーの『リファクタリング』は必読書だと思います。この古典ともいえる『テスト駆動開発』が和田さんの手によって新訳版として復刊されたことは、ほんとうにすばらしいことです。 この本が出版された経緯と、和田さんはじめ関係者の方々のご努力については、和田さんの、このブログをぜひ読んでいただければと思います。 新訳版『テスト駆動開発』が出ます 新訳本は、単に原著が日本語で読めるようになっただけではありません。和田さんの手によって、原著にはない新たな価値が付け加えらました。 一つは、サンプルコードの工夫です。 できるだけ省略はしない変更箇所を目立つようにした各章末にその時点での全コードを記載する これらの工夫により、本に書かれた内容が、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
