無限のメモリ空間と絶対に落ちないプロセスを仮定して「ビジネスロジック」をあぶり出す - assertInstanceOf('Engineer', $a_suenami)
先日、前職の上司から「そろそろプロフィールに"詩人"を追加するべきだ」と言われました a-suenami です。今日も今日とて詩人業を行なっていきますよ！ 「ビジネスロジック」とは何か 最近、業務で、比較的中長期的なアーキテクチャの見直しだったり、新機能の設計だったりをさせてもらう機会が増えた。 コンポーネントをどういう風に分割するかとか、それぞれのコンポーネントを主にどのチームでメンテナンスしていくかとか、そういうのを考えるのは楽しい反面、かなり熟慮に熟慮を重ねないといけないものでもあるのでかなり責任を感じるというのもある。 まあ、そんなこんなでいろいろうーんうーんって悩んでいると昔（たぶん DDD コミュニティだと思うけど）誰かに言われた「無限のメモリ空間と絶対に落ちないプロセスがあったとして、それでもそのコードを書かないといけないのならそれがあなたのドメインだ」という言葉だ。 モデリ
Railsでサービスとフォームを導入してみる話 - assertInstanceOf('Engineer', $a_suenami)
この記事はRuby on Rails Advent Calendar 2013の6日目の記事です。 前日は @tkawa さんの「Favoriteの設計実装はパターンとして使える」でした。 Railsで適切に責務を分割するということ RailsはいわゆるMVCと呼ばれるアーキテクチャパターンにのっとったフレームワークであり、プロジェクトを作成するとデフォルトでmodels/、views/、controllers/などのディレクトリが作成されます。 基本的にロジックを記述する場所はモデルであり、ビューには表示処理だけを、コントローラにはアプリケーション上必要な手続きだけを記述するべきであると一般的には言われています。*1 ただ、それを忠実に実践していった結果、モデルが肥大化しメンテナンシビリティやテスタビリティが低下するという問題も多く指摘されています。 これについては4日目に @joker
そろそろドメイン駆動設計はもうちょっとだけ細分化されるべき - assertInstanceOf('Engineer', $a_suenami)
昨日飲みながらドメイン駆動設計（以下、DDD）についてしゃべっていて思ったことを書く。 ドメイン駆動設計（DDD）って？ DDD とは何かという説明についてはぐぐったらたくさん出てくると思うので割愛。 Wikipedia の引用だけしておきます。（雑） ドメイン駆動設計 - Wikipedia ドメイン駆動設計（英: Domain-driven design, DDD）とはソフトウェアの設計手法であり、'複雑なドメインの設計はモデルベースで行うべきであり'、'また大半のソフトウェアプロジェクトではシステムを実装するための特定の技術ではなくドメインそのものとドメインのロジックに焦点を置くべき'とする。この名称は Eric Evans が同名の著作で用いた。 興味がある人はこちらを読んでください。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェ
要求の複雑性とアーキテクチャの複雑性 - assertInstanceOf('Engineer', $a_suenami)
なんか朝ふと考えたこと特にまとまってない状態で書いてみる。もしかしたら今年最後のエントリになるかもしれないエントリがそれでいいのかっていう気がしなくもないけど。 僕たちのようにソフトウェアをつくている人たちは本質的に複雑性に立ち向かうことが主な営みである。世の中というのは複雑であり、その複雑な世の中で問題とされていることを解決しようとするとその中でもとりわけ複雑な領域を取り扱わなければならない。そうでなければそもそもソフトウェアなど必要ないことになる。人間がそれをやるにはワーキングメモリが少なすぎるとか、時間がかかりすぎるとか、原因は何かわからないけど何らかの理由によりちゃんと遂行できないものこそソフトウェアをつくって解決するべきなのだということになる。 逆に言えば僕たちソフトウェア産業従事者が今も仕事を手に出来ていてちゃんとご飯が食べられているのは世の中が複雑であることの恩恵かもしれない
オブジェクト指向とは結局メンタルモデルのモデリング手法である - assertInstanceOf('Engineer', $a_suenami)
きしださんのエントリが話題です。 オブジェクト指向は禁止するべき - きしだのはてな 「禁止するべき」とはまた随分と煽りタイトルですねと思いつつも、内容自体はとても納得のいくものでした。 ただ「オブジェクト指向」というのはいろいろな観点で語られることが多く、多少モヤモヤとはしているので僕の考えを書いてみようと思います。 なお、きしださんご自身は以下の補足エントリで立場は明確にされています。本エントリはこれを否定するものではありません。あくまで違った立場からの意見です。*1 オブジェクト指向について - きしだのはてな 参考までに、ぼくの基本的な定義は、ランボーの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」という定義に従っています。そのようなオブジェクトが単体ではなく組織化されるということが重要です。オブジェクト指向を勉強するとはそのような組織
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
