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)は、「
みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆
どちらの無線規格もメリット・デメリットをあわせ持っています。それらは補完関係にあるため、無線化に必要な条件を明確にすることでおのずと選択肢は限られてきます。それぞれの特徴を理解し、用途に応じて使い分けることが重要です。 近年、組込み機器開発に利用される無線規格として、BluetoothとZigBeeの2つが挙げられます。2.4GHzという同じ周波数帯(ISM帯)を利用し、「低速」「近距離」「低消費電力」と似たような特徴を持つことから、何かと比較されることが多いBluetoothとZigBeeですが、それぞれがメリット・デメリットとなる特徴をあわせ持っており、それらは双方のメリット・デメリットを補完するようなものであることから、検討している無線用途に必要な条件を明確にしていくことで、おのずとどちらの無線規格を選べば良いのかしぼられてくるケースも少なくありません。まずはそれぞれの特徴をしっかり
ソースコード自動生成の黒歴史を塗り替えるブランコ Excelからプログラムを作る多言語対応オープンソース NTTデータ ビジネスブレインズ 伊賀敏樹 2007/12/25 開発現場の夢をかなえるブランコ ソフトウェア開発をしていて、「設計書を書き終わったら、そのままソースコードができちゃったらいいな」なんて思ったことはありませんか? この記事では、まさに「設計書(Excelブック形式)からソースコードを自動生成」してしまう「blanco Framework」(Sourceforgeのページ)というツールの紹介をします。 blanco Frameworkが提供しているExcel様式に、Microsoft Office(Excel)やOpenOffice.orgを使って所定の必要項目を記入すると、Java、.NET、JavaScript、PHP、Ruby、Pythonのソースコードが自動生成で
Webアプリケーション開発案件の短納期化、高品質化、低コスト化要求に応えるために、ソースコード自動生成技術を活用する手法が注目されている。アイデア自体は昔から存在するものの、これまで大きく普及してこなかった自動生成という分野が、いまなぜ再び脚光を浴びつつあるのか。開発現場では顧客の高品質化要求や短納期要求により、もはや5%や10%の生産性向上策では負荷を吸収できずにいる。思い切って生産性を5倍、10倍へと上げるためには「できるだけコードを書かない」という発想の転換を行うしかないと気付き始めてきたことが大きい。ここではその技術進化の過程を追っていくとともに、ソースコード自動生成技術分野の最新状況と、これによるソフトウェア開発作業の現場への影響を紹介する。 自動生成技術の歴史 ソースコードを自動生成させるという考え方自体は古く、FortranやCOBOLが全盛の時代から今日に至るまで、さまざま
今回はUMLよりOCL 今回は、UMLではなくUMLモデルを補助しそのモデル要素にかかわる制約を正確に表現することを目的に導入されたOCL(Object Constraint Language:オブジェクト制約言語)について簡単にご紹介しましょう。 なぜUMLだけでは足りないのか 皆さんの中にはUMLさえあれば、オブジェクト指向でモデルを完全に記述できるのではないかとお考えの人も多いでしょう。実際、UMLを利用することで、自然言語のあいまいさを減らして業務領域やシステム化対象の構造をより正確に表現できたり、逆にJavaで書いた何万行ものソースコードそのままよりは、それらのコードの構造や振る舞いを抽象化してビジュアルな全体感を持つのに有効そうと実感されているエンジニアの皆さんは多いと思います。 しかし、ビジュアルなモデルだけでは表現できない内容が普通に存在します。それは、クラス図がインスタン
本稿は、設計書の作成を必要とするソフトウェア開発を前提として書かれています。設計書の作成が必要ないソフトウェア開発においては、設計書からソースコードを自動生成するメリットはあまり出てこないでしょう。 ■ 【1】設計書どおりのソースコードが作られる 設計書からソースコード自動生成を行うと、機械的にソースコードが作成されるので、必然的に設計書どおりのソースコードが作られるようになります。人間が設計書を見ながらコーディングをしていると、どうしても間違いが混入してしまいますよね。設計書からソースコードを自動生成することによって、人為的ミスがかなり排除できるのです。 ■ 【2】ソースコードの均質化 ソースコード自動生成によって、強制的にソースコードの均質化が実現できます。クラス名、メソッド名などが機械的に命名されるので、コーディングルール徹底にも貢献できる場合があります。 ■ 【3】設計書が残る 「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く