以前のプロジェクトで、ドメインモデル貧血症なプログラムに悩まされたので、学んだことを書いてみます。 ドメインモデル貧血症とは オブジェクト指向におけるアンチパターン。 振る舞いとデータが分かれてしまっており、手続型の設計・実装になってしまう状態。 詳しくは以下のURLで。 Martin Fowler's Bliki in Japanese - ドメインモデル貧血症 自分なりの理解では、ドメインモデル=エンティティクラスと思ってます。 試しに以下のような従業員クラスでドメインモデル貧血症を考えてみたいと思います。 /** * 従業員クラス */ public class Employee { private int employeeId; private String familyName; private String firstName; private double weight; p
ドメインモデル貧血症、という言葉があります。 説明を引用すると、 大半がpublicなゲッターセッターで、単に属性と値を保持するだけのオブジェクト を、「ドメインモデル」と呼んでいる症状、とのことです。*1 そんなソースをつい最近見かけ、また、紛らわしい場合もあるので、それについて書いてみます。 忘れてはいけないこと publicなゲッターセッターのみのクラスが、全て貧血症、というわけではない。 意図してそうしているなら、それは問題ない。 見つけたソース(イメージ) Javaです。 貧血症クラス定義 public class TeamInfo { private String teamCode; private String teamName; private ArrayList<User> teamMember; public String getTeamCode(){/*省略*/};
【悲報】ゆうちょPayでは「佐々木」という姓が名前として入力できない。なんだこれ日本に佐々木姓が何人いると思ってんだ…… https://t.co/nrsMZ3sQJk
ナイスタイツ[弾]@避難所 @TightsNice 現在局所的に発生しているバグをまとめてみました ・個人プロフィールデータ(アイコン、ヘッダー、自己紹介欄等)がリセットされツイッター登録年月日が1970年1月登録に ・その状態で63歳未満の人が正しい生年月日を登録すると13歳未満でツイッター開始したんですね規約違反です!となります 続きます 2019-05-02 10:44:58 ナイスタイツ[弾]@避難所 @TightsNice ・生年月日を入力しなかったり自分は63歳以上ですと偽ればそのまま問題無く継続出来る ・上記の理由での凍結が発生した状態のアカウントでヘルプページから凍結の異議申し立てのページのリンクへ飛ぼうとしてもヘルプページトップに強制的に戻されてしまう ・異議申し立ての手段が完全に閉ざされる 2019-05-02 10:49:29
目次 プログラミングの変数・メソッドの命名でよく使う英単語 ログイン・認証 許可・権限 ネットワーク ファイル操作 外部入出力 データ入出力 データベース操作 オブジェクト操作 生成・構築 削除・破棄 変更 変換・結合・排除 分割・切り出す(スライス) 登録・設定 検索・置き換え 状態・状態変更 計算 プロセス操作 処理サイクル 確認(1) 確認(2) 比較 その他対で使う単語 コード・ID・引数(変数) 機械学習関連 その他(未分類) データベーステーブルのカラム名の工夫(変数) 変数の頭につける接頭語 プログラミングの変数・メソッドの命名でよく使う英単語 プログラミング時の「メソッド名」「変数名」の命名で使いそうな英単語を「同じ意味でもニュアンスによって使い分けされるもの」あたりを注意してまとめます。 ログイン・認証 単語 意味 log_in/log_out ログインする/ログオフする
raydive.hatenablog.jp 続き。 Chapter 3 A Functional Architecture この章からドメインをソフトウェアアーキテクチャに変換していくところに入る。その前にソフトウェアアーキテクチャ自身もドメインだよねと、用語を定義するためにC4モデルを導入する。C4モデルの自分の理解としてはこんな感じ。 本の例だと、境界付けられたコンテキストとして今着目しているOrder-Taking ContextをDeployableなContainerとして話を進めている。*1境界付けられたコンテキスト間のやり取りにDTOやキューを導入したり、またコンテキスト間の決め事に三パターンあげている。 Shared Kernel Customer/Supplier (Downstream contextが基準作って、upstreamがそれに乗っ取る) Conformist
Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# 作者: Scott Wlaschin出版社/メーカー: Pragmatic Bookshelf発売日: 2018/02/04メディア: ペーパーバックこの商品を含むブログを見る 今Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# (English Edition)という本を読んでいる。自分で理解で端的に書くならば、ドメイン駆動設計をFunctional Programmingに落とし込んでいくためのどう考えるか・どうするか?を述べている本だと思う。今、社内で輪読会が行われて
確認してみたところコーディングを支える技術には「名前的型システムと構造的型システムの違い」について書かれていなかった。これを加筆したいが媒体の都合で大幅な加筆は難しいのでここにドラフトを置く。
いきなりですが、n月刊ラムダノートが創刊されました。めでたい。 www.lambdanote.com で、この中にある @mametter さん執筆の記事『「コルーチン」とは何だったのか?』に僕はがっつり関わっていました。 後述しますが、僕と彼とのオンラインでのやり取りの中で記事が書き始められ、方針が決まっていった感じです。 なので、出版を記念してそのへんの経緯を振り返り、また僕なりの感想をまとめようかと思います。 ……と思ったんですが、改めてやりとりのログを見返してたんですがアホほど膨大な量になっていて、とても全部振り返るのは無理だと悟りました。 なのでざっくりと。 当該の記事と一緒に読まれることを想定していますので、その記事で語られていることの説明はある程度省いています。 数時間前に @mametter さんが草稿を公開↓したので、そちらを読んでくれても構いません(できれば買ってほしい
ドメイン駆動設計との出会い 10年前に、エヴァンスのドメイン駆動設計を初めて読んだ時は、書いてある内容がほとんど理解できなかった。 あまり、面白いとも思わなかった。 当時は、現場でバグだらけのコードと格闘していた。障害が報告されるたびに、リファクタリング本を参考に、該当個所の長いメソッドや大きなクラスを片端からリファクタリング。その結果、コードがわかりやすくなり、やっかいなバグが単純な修正で解消できてしまうことの効果に驚き、設計の重要性を再認識していた。 それ以前は、UNIXとC言語、OracleとPL/SQLという、オブジェクト指向ではない世界で技術を身に着けてきた。 どちらかというとオブジェクト指向には、ネガティブな印象を持っていた。現場では役に立たんだろうと。 バグとの格闘の中で、リファクタリング(設計改善)の威力を肌で感じ、その考え方とやり方がオブジェクト指向に由来するということを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く