CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
イミュータブルデータモデル - kawasima
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
増田亨さんによる「設計の考え方とやり方」勉強会 書き起こし4 「開発のやり方と設計スキルと補足資料」 - asken テックブログ
増田亨さんによる「設計の考え方とやり方」勉強会 書き起こし4ページ目です。最初からお読み頂く場合は、こちらから御覧ください。 資料 増田さんの講演資料 質疑応答モデル なぜこの場を作ったのか 書き起こしリンク パート1「良い設計を目指す」 パート2「設計スタイルの選択とクラス設計のスタイル」 パート3「テーブル設計のスタイル」 パート4「開発のやり方と設計スキルと補足資料」（本記事） パート5「質疑応答」 目次 開発のやり方 開発のやり方の分かれ道 組み立て思考の開発のやり方 変化しやすい構造を作る とっとと作る 設計スキルを身につける 設計スキル 設計スキルアップの行動計画 まとめ 補足資料 開発のやり方 開発のやり方の分かれ道 簡単に言うと、目的の固定から出発する分解思考の開発のやり方がかつての潮流でした。タスク分解して、工程分解して分業体制にして、その結果実際に作っている人間の後半の
ドメイン駆動 + オニオンアーキテクチャ概略[DDD] - little hands' lab
DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か 背景 ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かの記事で、オススメしていたのはオニオンアーキテクチャでした。 今回は、オニオンアーキテクチャについて詳しく説明したいと思います。 上述の記事でも書いた通り、「ヘキサゴナル、オニオン、クリーン」の3つは、本質的には全く同じで、思想としてはヘキサゴナルで完成されているのですが、より具体的に説明されているオニオンアーキテクチャから説明を読んだ方が理解がしやすいと思います。 その後にヘキサゴナルの説明を読むと「なるほど」となって「あれ、結局ヘキサゴナルじゃん」と
![ドメイン駆動 + オニオンアーキテクチャ概略[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/08f5c6031dd21f86d259a1d9e9f6383a3180a1cb/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171011%2F20171011062558.png)
レイヤードアーキテクチャの視点 - Qiita
「ValueObjectという考え方」でDDDの片鱗について書かせていただきました 今回はDDD本のなかでも少し抽象度の高い「レイヤードアーキテクチャ」について深堀っていきます レイヤードアーキテクチャとは レイヤーアーキテクチャ・レイヤードアーキテクチャと呼ばれているこのアーキテクチャ指向です DDDは特定技術へ依存しているわけではないのでDDD=レイヤードアーキテクチャ！とならないように気をつけましょう 上位互換の思想として以下のものがあります ヘキサゴナルアーキテクチャ オニオンアーキテクチャ クリーンアーキテクチャ 基本的にどのアーキテクチャも一貫して責務を適切に設定して依存関係を明確にするという目的があります 一番原始的（？）なレイヤードアーキテクチャはその名の通り 責務を適切に設定した塊＝層（レイヤー）をイメージします これだけじゃなんのことやらって感じですね 更に技術っぽい責
やっと「依存性の逆転(Dependency Inversion)」がわかった - Qiita
依存性逆転の原則 - Wikipedia オブジェクト指向設計において、依存性逆転の原則、または依存関係逆転の原則[1]（dependency inversion principle) とはソフトウエアモジュールを疎結合に保つための特定の形式を指す用語。この原則に従うとソフトウェアの振る舞いを定義する上位レベルのモジュールから下位レベルモジュールへの従来の依存関係は逆転し、結果として下位レベルモジュールの実装の詳細から上位レベルモジュールを独立に保つことができるようになる。この原則で述べられていることは以下の２つである:[2] A. 上位レベルのモジュールは下位レベルのモジュールに依存すべきではない。両方とも抽象（abstractions)に依存すべきである。 B. 抽象は詳細に依存してはならない。詳細が抽象に依存すべきである。 正直こういうのを見てもいまいちわかってなかった。 しかし、よ
「依存性逆転の原則」の自分なりの解釈 - 圧倒亭グランパのブログ
「依存性逆転の原則（DIP：Dependency Inversion Principle）」に関して考える機会があり、自分なりに言語化できそうなのでまとめます。ご指摘は大歓迎です。 目次 目次 TL;DR 考えるきっかけ 具体例から紐解いていく べた書きのモジュールA モジュール分割による依存性の出現 モジュールの安定性 安定依存の原則 （SDP: Stable Dependencies Principle） 間違った「依存方向の逆転」 DIPに基づいた「依存方向の逆転」 まとめ TL;DR より安定したモジュールの方向へ依存するよう設計し、ソフトウェアの安定性を高めることが重要 不安定なモジュールが 依存されている と修正範囲が大きくなるため、 依存されない ようにしたい。そのために、依存方向を逆転させたい DIPは「モジュールへの依存方向は逆転可能」ということを示し、「その方法」を解説
システムの寿命はコードで決まる！（1/3） ― ＠IT
コードはシステムの寿命に大きな影響を与えます。今回は、コードとデータベースエンジニアの関係を通してこのことを解説します。ここでいうコードとは、顧客ID、受注伝票番号など、業務上利用されるデータを識別・分類するため、各データの本来の名前とは別に割り当てられる記号のことです。 データベースエンジニアにはデータ設計とデータベース設計の2つの役割があります。そして、データベースエンジニアにはデータ設計の一環として安定したコード体系を設計し、データベースをコード体系に依存しないように設計することが求められます。 システムを長く使い続けるためには、 コード体系を長期にわたり変更せず利用できるようにすること コード体系とデータベース設計との結合度を小さくすること が重要です。なぜなら、コードのけたが足りなくなったり、コードの分類が業務にそぐわなくなったりして、コード体系の見直しを行うことになると、業務・
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
