コンテンツにスキップ

利用者:Br3kyokyo/sandbox

< 利用者:Br3kyokyo

これはこのページの過去の版です。Br3kyokyo (会話 | 投稿記録) による 2024年9月4日 (水) 21:01 （個人設定で未設定ならUTC）時点の版であり、現在の版とは大きく異なる場合があります。

選挙方式の種別

選挙制度の最も一般的な区分としては、「単数選出」と「複数選出」、「比例代表制」と「勝者総取り」と「混合選挙制度」がある。

単数選出、勝者総取り方式

全体で1人だけが選出される場合、選挙制度は常に勝者総取り方式である。1つの選挙区に対して1人だけが選出される場合も、同様のことが言える。選挙区は勝者総取りであるため、全体としても選挙制度は非比例的となる。（単一選挙区において）一度に複数人が選出される場合も、勝者総取りである。

政党ブロック投票においては、投票者は候補者個人に対してでなく、政党の候補者リストに対して投票し、最も多くの票を得た政党がすべての議席を獲得する。これは五カ国で混合選挙制度の一部として採用されている。[1]

相対多数投票と相対多数代表制（first-past-the-post, FPTP）

相対多数投票（英語版）は、最も多くの票を獲得した候補者一人、あるいは複数人が当選する方式であり、票全体の過半数を獲得する必要はない。一人が一候補者のみを選択する場合、これはfirst-past-the-post（英語版）（相対多数代表制[2], FPTP, 単純小選挙区制）と呼ばれ、これは国家の立法機関の選挙制度としては二番目に多く、58カ国に採用されており、[3]その大部分はイギリスやアメリカの植民地、または領土であった国々である。FPTPはまた、大統領選挙にも二番目に多く、19カ国で採用されている。[3]　（単純小選挙区制は、相対多数代表制を採用している。）

一人が複数票を投じる場合は、定数が複数の選挙区であることが最も一般的であり、この場合、選挙制度にはいくつかの種類が存在する。ブロック投票（連記非移譲投票、multiple non-transferable, plurality-at-large)においては、投票者は選挙区定数と同数の票を、その政党に関わらず、任意の候補者に対して投じることができる。この方式は、8カ国で採用されている。[4]

認定投票は、多数派の支持を得て当選する候補者の数を増やすことを目的とした方式[5]で、これはchoose-all-you-likeと呼ばれ、投票者は好きなだけ多くの候補者を選ぶことができる。投じられた全ての票は投票者が選択した候補者の数に関わらず同等の重さとして扱われ、最も多くの票を獲得した候補者が当選する。[6]

決選投票方式

決選投票システムでは、候補者が当選するには票の過半数を得る必要がある。これは決選投票や最終ラウンド投票で行われる。この方式は過半数投票の一種として言及されることがあるが、勝敗が決まる最後のラウンドで必要とされる票は相対多数（英語版）で済むことが多い。さらには、過半数を得ていない第一ラウンドでの勝者が第二ラウンドに進むことなく当選を決めることさえある。社会選択理論においては、決選投票システムは過半数投票とは呼ばれず、コンドルセ方式（英語版）と呼ばれる。

決選投票システムには二つの主要な形式がある。一つは優先度付投票を用いて単一ラウンドで行われるもので、もう一つは複数回の投票により候補者を段階的に絞り込むものである。どちらも主に、単一議席の選挙区で行われる。

決選投票システムでは、優先順位付投票（即時決選投票, 英語: Instant run-off voting, IRV）を用いて一回の選挙で結果を確定させることができる。この方法では、投票者は好みに応じて候補者を順位づけする。この制度はオーストラリアとパプアニューギニアの議会選挙で用いられている。初回投票で過半数の票を得た候補者がいなかった場合、最下位の候補者を落選として次点の選好票が他の候補者に配分される。この手続きを、一人の候補者が有効投票数の50%の票を得るまで繰り返す。全ての投票者が全ての選好票を行使しない場合、候補者が二人になるまで手続きが進むこともあり、その時点での最多得票者が当選となる。IRVを修正したものがContingent vote（英語版）で、投票者は全ての候補者のランク付けするのではなく、限られた数の選好票を持つ。初回ラウンドでどの候補者も過半数票を得なかった場合は、トップ二人を除く全ての候補者が除外され、除外された候補者の分の選好票が残った候補者に加算されて勝者が決定される。このシステムはスリランカの大統領選挙で用いられ、投票者は三人の選好票をもつ。[7]

決選投票システムのもう一つの主要な形式が、二回投票制である。これは大統領選挙においては最も一般的な形式であり、88カ国によって採用されている。これは立法府の選挙においても20カ国によって採用されている。[8] 第一ラウンドで過半数を得た候補者がいなかった場合、勝者を決定するために第二ラウンド投票が行われる。ほとんどの場合において、第二ラウンドは第一ラウンドでのトップ二人に限られるが、いくつかの選挙では複数の候補者が第二ラウンドに参加することがあり、その場合は相対多数により勝者が決定される。いくつかの国では二回投票制の修正版が用いられ、例えばエクアドルの大統領選挙では、ある候補者が40%を得票しかつ、次点の候補者に10%の差をつけている場合、勝利が宣言される。[9] また、アルゼンチンにおいては、45%の得票と10%の差であり、この制度はバロタージュ（英語版） として知られている。場合によっては、決選投票が他のシステムを用いて行われることもあり、アメリカ選挙人団の過半数をどの候補も獲得しない場合の臨時選挙（英語版）がこれに該当する。

徹底投票（英語版）は投票回数を二回に限らず、各投票ラウンドで最下位の候補者が落選する。このシステムでは多くの投票回数が発生する可能性があるため、主要な選挙では採用されていないが、いくつかの国の議会議長選挙と、スイス連邦参事会参事の選挙で採用されている。一部形式では、一人の候補者が過半数を獲得するまで候補者が脱落せずに複数回の投票が行われることもある。

複数選出方式

比例方式

比例代表制は国家における立法府選挙において最も広く使われている選挙方式であり、80カ国以上の議会がさまざまな形で比例方式を用いて選出されている。80カ国以上の議会がさまざまな形で選出されている。

Proportional representation is the most widely used electoral system for national legislatures, with the parliaments of over eighty countries elected by various forms of the system.

Party-list proportional representation is the single most common electoral system and is used by 80 countries, and involves voters voting for a list of candidates proposed by a party. In closed list systems voters do not have any influence over the candidates put forward by the party, but in open list systems voters are able to both vote for the party list and influence the order in which candidates will be assigned seats. In some countries, notably Israel and the Netherlands, elections are carried out using 'pure' proportional representation, with the votes tallied on a national level before assigning seats to parties. However, in most cases several multi-member constituencies are used rather than a single nationwide constituency, giving an element of geographical representation; but this can result in the distribution of seats not reflecting the national vote totals. As a result, some countries have leveling seats to award to parties whose seat totals are lower than their proportion of the national vote.

比例代表制は、国会議員選挙において最も広く使用されている選挙制度であり、80か国以上の議会がこの制度のさまざまな形式で選出されている。

政党リスト比例代表制は、単一で最も一般的な選挙制度であり、80か国で使用されている。この制度では、有権者が政党によって提案された候補者リストに投票する。クローズドリスト制度では、有権者は政党が提案した候補者に対して影響を与えることはできないが、オープンリスト制度では、有権者は政党リストに投票するだけでなく、候補者が議席に割り当てられる順序にも影響を与えることができる。イスラエルやオランダなど一部の国では、純粋な比例代表制を使用して選挙が行われ、全国レベルで集計された票に基づいて政党に議席が割り当てられる。しかし、ほとんどの場合、全国規模の選挙区ではなく、複数の議席を持つ選挙区が使用され、地理的代表性の要素が加わる。このため、議席の分配が国全体の得票率を反映しないことがある。その結果、いくつかの国では、全国投票割合に比べて議席数が少ない政党に議席を割り当てる調整議席を設けている。

徹底投票は2回の投票に限定されず、各投票ラウンドで最下位の候補者が除外される。このシステムは、多くのラウンドが発生する可能性があるため、主要な人気選挙では使用されないが、いくつかの国の議会議長やスイス連邦参事会のメンバーを選出するために使用されている。一部の形式では、候補者が過半数を獲得するまで、候補者が除外されない複数のラウンドが行われることもある。

総当たり投票は2回に限られず、各回で最下位の候補者が落選する。投票回数が多くなる可能性があるため、この方式は主要な一般選挙では採用されていないが、いくつかの国の国会議長やスイス連邦議会の議員を選出する際には採用されている。候補者が過半数に達するまで、候補者を一人も落選させることなく複数回の投票を行う方式もある。

いくつかの国では、二回投票制の修正版が使用されている。例えば、エクアドルでは大統領選挙で候補者が40％の票を得て、最も近い対立候補に10％以上の差をつけた場合、勝者として宣言される。また、アルゼンチンでは（45％以上かつ対立候補に10％以上の差）であり、このシステムは「バロタージュ」として知られている。場合によっては、決選投票が異なる制度を使用して行われることもあり、例えば、アメリカ合衆国の選挙人団で過半数を獲得する候補者がいない場合の条件付き選挙がこれに該当する。

エキゾースティブ・バロット（exhaustive ballot）は、二回に限定されず、各投票ラウンドで最下位の候補者が排除される。この制度はラウンド数が多くなる可能性があるため、主要な人気選挙では使用されないが、いくつかの国の議会議長やスイス連邦評議会のメンバーを選出する際に使用されている。形式によっては、候補者が過半数を得るまで、候補者が排除されない複数のラウンドが行われる場合もある。




ドメイン、または事業活動、事業領域とは、ソフトウェア工学において、あるソフトウェアが対象とする領域[10]のことである。形式的には、それが定義されている範囲の広さに関わらず、特定のプログラミングプロジェクトの対象領域を表現するものである。[11]

事業領域は、複数の業務領域に分割できる。

ドメイン駆動設計, DDDにおいては、事業領域内において同じ言葉を使うことによって、業務エキスパートと開発者間での事業活動に対する共通理解を形成しようとする。ここで、同じ言葉は同じ意味を持ち、すなわち同じ業務ロジックを持つことになる。ただし、同じ事業領域内においても、文脈が違えば同じ言葉が異なった意味を持つ場合が存在する。そこで、ドメイン駆動開発では区切られた文脈を導入し、文脈ごとに異なる言葉の意味を明確にする。すなわち、区切られた文脈の中では、同じ言葉は同じ意味を持つことになる。

ここで、同じ言葉は同じ意味を持ち、同じ業務ロジックを持つことになる。ただし、事業領域内においても、文脈が異なればその意味が異なる場合もある。そこで、ドメイン駆動設計では区切られた文脈を導入することによって、文脈によって異なる言葉の意味を明確にする。

区切られた文脈内においては、同じ言葉は同じ意味を持ち、すなわち同じ業務ロジックを持つ。

領域内での業務ロジックを整理しようとする。ただし、事業領域内においても、文脈が異なれば意味が異なる場合も存在する。そこで、ドメイン駆動設計では区切られた文脈を導入することによって、文脈によって異なる言葉の意味を明確にする。区切られた文脈内においては、同じ言葉は同じ意味を持ち、すなわち同じ業務ロジックを持つ。

ドメイン駆動設計においては、区切られた文脈を導入することによって、文脈によって異なる言葉の意味を明確にする。区切られた文脈内においては、

文脈ごとに一つの言葉に対して一つの業務ロジックを与える。区切られた文脈内においては、同じ言葉は同じ意味を持ち、すなわち同じ業務ロジックを持つことになる。区切られた文脈を適当に設計することが、ドメイン駆動設計の核心的な考え方である。

区切られた文脈は、言語学における「意味論的な領域」に基づいていると考えられる[10]。意味論的な領域とは、同じ言葉が同じ意味で使われる範囲のことを指す。

文脈ごとに言葉に対して一つの業務ロジックを与える。

事業領域内においては同じ言葉に対して同じ業務ロジックを定義する。ドメイン駆動設計では、区切られた文脈を導入することによって、文脈によって異なる言葉の意味を明確にする。[10]

1883 年にアメリカ合衆国は野菜の輸入に10%の税金をかけました。しかし果実は 非課税です。植物学的にはトマトは果実であるとして、トマトの輸入業者は税金を 払おうとしませんでした。この抜け穴をふさぐために、1893 年に合衆国の最高裁判 所は「トマトは野菜である」という判決を下しました。その結果、合衆国の課税制 度という区切られた文脈では、トマトは野菜です。

ドメイン駆動設計においては、区切られた文脈内においては同じ言葉に対して同じ業務ロジックを定義する。ドメイン駆動設計では、区切られた文脈を導入することによって、文脈によって異なる言葉の意味を明確にする。[10]

つまり、言葉の意味はそれを使う場所によって変化する、という事実をそのままソフトウェア設計に落とし込んだのがドメイン駆動設計である。

ドメインモデルは区切られた文脈によって明確に定義された言葉に属するロジックを表現するオブジェクトモデル[10]である。ドメインモデルは、事業領域ごとに個別に定義される。同じ言葉のドメインモデルであっても、事業領域が異なれば、

区切られた文脈

ここで、同じ言葉というのがドメインモデルである。

つまり、言葉の意味はそれを使う背景によって変化する、という事実をソフトウェアに落とし込んだものがドメイン駆動設計である。

形式的には、それが定義されている範囲の広さに関わらず、特定のプログラミングプロジェクトの対象領域を表現するものである[11]。

ソフトウェア工学において、ドメインとはコンピュータプログラムが対象とする領域のことである。形式的には、それが定義されている範囲の広さに関わらず、特定のプログラミングプロジェクトの対象領域を表現するものである。[11]　例えば、ある病院のためのコンピュータプログラムを作成することを目的としたプロジェクトがある場合、その病院がドメインとなるし、そのスコープを"すべての病院"に拡張すれば、"すべての病院"がそのドメインとなる。コンピュータプログラミング設計においては、

ソフトウェア工学の領域におけるドメインは一般に、アプリケーションが適用しようとする対象の領域のことを指す。言い換えれば、アプリケーション開発において、ドメインとは、「アプリケーションのロジックが関係する知識と活動の領域」である。ー Andrew Powell-Morse[12]

ドメイン: 知識、影響力、活動の領域。ユーザがプログラムを適用する対象領域をソフトウェアのドメインと呼ぶ。ー エリック・エヴァンス（英語版）[13]

In software engineering, domain is the targeted subject area of a computer program. Formally it represents the target subject of a specific programming project, whether narrowly or broadly defined.[11] For example, for a particular programming project that has as a goal of the creation of a program for a particular hospital, that hospital would be the domain. Or, the project can be expanded in scope to include all hospitals as its domain.[11]:352 In a computer programming design, you define a domain by delineating a set of common requirements, terminology, and functionality for any software program constructed to solve a problem in the area of computer programming, known as domain engineering. The word "domain" is also taken as a synonym of application domain.[11]

Domain in the realm of software engineering commonly refers to the subject area on which the application is intended to apply. In other words, during application development, the domain is the "sphere of knowledge and activity around which the application logic revolves." —Andrew Powell-Morse[12]

Domain: A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software. —Eric Evans[13]

ドメインとは、コンピュータープログラミングの分野で問題を解決するために作られる任意のソフトウェアプログラムに対して、一般的な要求、用語、機能を定義する研究分野である。ドメイン・エンジニアリングとしても知られる。ドメインという単語は、「アプリケーションドメイン」の同義語としても使われる[14]。また、知識の範囲（sphere of knowledge）という意味でも使われる。





ドメイン、または事業活動、事業領域とは、ソフトウェア工学において、あるソフトウェアが対象とする領域[15]のことである。形式的には、それが定義されている範囲の広さに関わらず、特定のプログラミングプロジェクトの対象領域を表現するものである[16]。 例えば、ある病院のためのコンピュータプログラムを作成することを目的としたプロジェクトがある場合、ドメインはその病院であり、そのスコープを「すべての病院」に拡張した場合、そのドメインは「すべての病院」である。コンピュータプログラミング設計においては、コンピュータプログラミングの領域において、ある問題を解決するために構築されたソフトウェアプログラムに共通する要件、用語、機能の教会を明確にすることによってドメインを定義することができ、これはドメインエンジニアリングと呼ばれる[16]。「ドメイン」という言葉は、「アプリケーションドメイン」の同義語としても用いられる。

ソフトウェア工学の領域におけるドメインは一般に、アプリケーションが適用しようとする対象の領域のことを指す。言い換えれば、アプリケーション開発において、ドメインとは、「アプリケーションのロジックが関係する知識と活動の領域」である。ー Andrew Powell-Morse[17]

ドメイン: 知識、影響力、活動の領域。ユーザがプログラムを適用する対象領域をソフトウェアのドメインと呼ぶ。ー エリック・エヴァンス（英語版）[18]

ドメイン駆動設計（DDD）におけるドメイン

ドメイン駆動設計（DDD）においては、事業領域内において同じ言葉を使うことによって、ある事業活動に対する共通理解を形成する[15]。ここで、同じ事業領域内においても、文脈が違えば同じ言葉が異なった意味を持つ場合が存在する。そこで、ドメイン駆動開発では区切られた文脈という概念を導入し、文脈ごとに異なる言葉の意味を明確にする[15]。これにより、区切られた文脈の中では、同じ言葉が同じ意味を持つことになる。これはつまり、同じ言葉が同じ業務ロジックを持つということであり、この区切られた文脈を適当に設計することが、ドメイン駆動設計の核心的な考え方の一つである。

ドメインモデルは区切られた文脈によって明確に定義された言葉に属するロジックを表現するオブジェクトモデル[15]である。区切られた文脈の導入により、同じ名前のドメインモデルであっても、文脈が異なれば、異なるロジックを持つことがある。例えば「見込み客」という言葉である。この言葉はある文脈においては「自社の製品に興味を持った」という意味であり、また他の文脈においては「営業プロセスにおいて取り組むべき対象」という意味である[15]。これらの文脈においてはそれぞれ異なる業務ロジックが要求される。

区切られた文脈は、言語学における「意味論的な領域（英語版）」に基づいていると考えられる[15]。ここで、意味論的な領域とは、同じ言葉が同じ意味で使われる範囲のことを指す。例えば「トマト」という言葉を例に挙げると、植物学の文脈においてはトマトは「果実」である一方で、アメリカの課税制度の文脈においてはトマトは「野菜」である[15]。ここで、「植物学」と「アメリカの課税制度」はそれぞれ意味論的な


「過半数」との違い

ヘンリー・シェルマース（英語版）は「”多数”を分類する用語は完全に一貫してはいないが、ここでは”多数”を4種類に分類する」とし、「多数」を単純多数、特別多数、相対多数、絶対多数に分けた[19]。このうち、

単純多数

シェルマースとドゥハティ、エドワードは「単純多数」を、棄権票を除いて過半数の票が必要とされるとした[19][20]。国際組織法における多くの司法管轄において、「単純多数」は「相対多数」よりも強い（しかし「絶対多数」よりは弱い）要件を持ち、棄権票を除いて過半数の票が必要とされる[21][22]。 ウィリアム・ライカーは、「単純多数[23]（英語: Simple majority）」を、棄権票を除いて複数の選択肢のうち最も多くの票を得たもの、つまり相対多数を指すとした[24]。

絶対多数

ライカーは「絶対多数（英語: Absolute majority)」を、全体のうち過半数の票を得た状態とし、棄権を母数から除くかは場合によるとした[24]。ドゥハティとエドワードは、投票権を持つ人のうち過半数のことを指すとし、棄権は反対と同様の意味を持つとしている[20]。一方、シェルマースは絶対多数を「他のいかなる選択肢が同時に得票可能性のあるより多くの」票数であるとし、「複数の候補があるとして、単数選出の場合は単純多数と同様だが、複数選出の場合は異なる」と指摘した。例えば、50人の投票者が6人を選出するために300票を投じる場合、ここでの絶対多数とは「空席の数を超えて候補者が選出されないために必要な最小限の票数」であるとし、この場合は6人が同時に43票を獲得することができる一方で、7人が同時に43票を獲得することはできないため、絶対多数は43となる[19]。42票では、7人同時に得票可能性があるため、落選する可能性があり、絶対多数とはいえない。

特別多数

「特別多数（英語: Qualified majority）」は、特定の割合以上の得票を得た状態（e.g. 3分の2以上）をいう[19]。

「相対多数（英語: relative majority, plurality）」は他のすべての選択肢より多くの票を得た状態をいう[19]。

曖昧さ回避 「過半数」のその他の用法についてはについては「マジョリティ」をご覧ください。

For other uses, see Majority (disambiguation). For majority votes as a social choice rule, see Majority rule.

過半数は全体の半分以上であることを指す。集合の半分以上の要素を含む部分集合である

A majority is more than half of a total. It is a subset of a set consisting of more than half of the set's elements. For example, if a group consists of 31 individuals, a majority would be 16 or more individuals, while having 15 or fewer individuals would not constitute a majority.

A majority is different from a plurality (which is a subset larger than any other subset, but not necessarily more than half the set). For example, if there is a group with 20 members which is divided into subgroups with 9, 6, and 5 members, then the 9-member group would be the plurality. A plurality is not necessarily a majority, as the largest subset considered may consist of less than half the set's elements, if there are three or more possible choices.




主要な概念

同じ言葉（ユビキタス言語）

同じ言葉とは、ドメイン駆動設計の中核的な考え方であり、

区切られた文脈（境界づけられたコンテキスト）

事業領域

ドメインモデル

集約

値オブジェクト

エンティティ

ドメインモデル


ドメイン駆動設計（ドメインくどうせっけい、英語: domain-driven design、DDD）は主要なソフトウェア設計手法の一つであり[25]、モデルをドメインエキスパートの知識に基づくドメインに一致させることに主眼を置くものである[26]。DDDは”単一の統一されたモデル”という考え方に反対し、1つの大きなシステムを複数の区切られた文脈に分割する。区切られた文脈は、それぞれが個別に自らのモデルを持つ[27]。

DDDにおいては、ソフトウェアコード（e.g. クラス名、クラスメソッド、クラス変数）における「言葉」や構造をビジネスドメインに一致させる必要がある。例えば、ソフトウェアがローン申請(loan application)を処理する場合、ソフトウェアは「loan application」「customer」といった名前のクラスや「accept offer」「withdraw」といったメソッドを持つことが考えられる。

DDDは以下のような目的に基づく。

  • プロジェクトにおける主な焦点を中核の業務領域（コアドメイン）と業務ロジック（ドメインロジック）のレイヤーに置くこと
  • 複雑な設計をドメインモデルで表現すること
  • 技術者とドメインエキスパートの間にクリエイティブな協働関係を構築し、特定のドメイン問題を扱う概念的なモデルを継続的に洗練させること

ドメイン駆動設計には、開発者がドメインモデルを純粋で有用な構造として維持するためには、通常大量の分離とカプセル化を行う必要があるという批判がある一方で、DDDは保守性などの利点を提供する。Microsoftは、ドメインに対する共通理解を構築することで明確な利点のある複雑なドメインにのみDDDを導入することを推奨している[28]。

DDDという名称は、エリック・エヴァンス（英語版）による著書の中で初めて提唱されたものである[29]。

概要

DDDは、多くの高水準な概念と実践を明確に示している[30]。もっとも重要なものは、ソフトウェアにおける「ドメイン」であり、これはユーザがプログラムを適用する対象領域を指す。「ドメインモデル」は、特定のドメインのある側面を表現し、ドメインにおける問題を解決するために用いることができるような抽象化のシステムである。

DDDにおいては、事業領域（ドメイン）内において同じ言葉を使うことによって、ある事業におけるドメインエキスパートとエンジニア間での事業活動に対する共通理解を形成する[31]。ここで、同じ事業領域内においても、文脈が違えば同じ言葉が異なった意味を持つ場合が存在する。そこで、ドメイン駆動開発では区切られた文脈という概念を導入し、文脈ごとに異なる言葉の意味を明確にする[31]。この区切られた文脈を適当に設計することが、ドメイン駆動設計の核心的な考え方の一つである。

DDDの考え方には、業務領域を中核の業務領域（コアドメイン）、一般的な業務領域（ジェネリック・サブドメイン）、補完的な業務領域（サブドメイン）に分け、それぞれに最適な実装方法を選択することを含む。一般に、複雑な業務ロジックを含む中核の業務領域には、ドメインモデルや、イベント履歴式のドメインモデルを用いることが適している[31]。

Kinds of models

ドメイン駆動設計におけるモデルには複数の種類がある。例えば、エンティティは属性でなく、識別子によって定義されるオブジェクトである。例えば、ほとんどの航空会社はすべてのフライトにおいて席に対して一意の数字を割り当てている。これは席の識別子である。これとは対照的に、値オブジェクトは属性を持つ一方で、概念的な同一性を持たないイミュータブルなオブジェクトである。例えば、例えば、ある人が名刺を交換する際を例に挙げると、この時名刺を交換する人は名刺の内容（属性）のみに関心があり、名刺一枚一枚を個別に扱うことはない。

Domain-driven design recognizes multiple kinds of models. For example, an entity is an object defined not by its attributes, but its identity. As an example, most airlines assign a unique number to seats on every flight: this is the seat's identity. In contrast, a value object is an immutable object that contains attributes but has no conceptual identity. When people exchange business cards, for instance, they only care about the information on the card (its attributes) rather than trying to distinguish between each unique card.

Models can also define events (something that happened in the past). A domain event is an event that domain experts care about. Models can be bound together by a root entity to become an aggregate. Objects outside the aggregate are allowed to hold references to the root but not to any other object of the aggregate. The aggregate root checks the consistency of changes in the aggregate. Drivers do not have to individually control each wheel of a car, for instance: they simply drive the car. In this context, a car is an aggregate of several other objects (the engine, the brakes, the headlights, etc.).

Working with models

In domain-driven design, an object's creation is often separated from the object itself.

A repository, for instance, is an object with methods for retrieving domain objects from a data store (e.g. a database). Similarly, a factory is an object with methods for directly creating domain objects.

When part of a program's functionality does not conceptually belong to any object, it is typically expressed as a service

モデルは、過去に起こった出来事（イベント）を定義することもできる。ドメインイベントとは、ドメインの専門家が関心を持つイベントのことである。モデルは、ルートエンティティによって結び付けられることでアグリゲート（集約）になることができる。アグリゲートの外部にあるオブジェクトは、ルートへの参照を保持することは許されるが、アグリゲート内の他のオブジェクトへの参照を保持することは許されない。アグリゲートのルートは、アグリゲート内の変更が一貫性を保つようチェックする。例えば、ドライバーは車の各ホイールを個別に操作する必要はなく、ただ車を運転するだけである。この文脈では、車はエンジン、ブレーキ、ヘッドライトなどの複数のオブジェクトを集約したものと言える。

説明

主要な概念

戦略的設計では、どのようにソフトウェアを設計するか、そしてなぜそうするかということを扱う[31]。戦略的設計とはDDDの核心であり、戦略的設計で示された方針を実現するために戦術的設計を行う。対して、DDDにおける戦術的設計における考え方のみを利用する場合、これは軽量DDDと呼ばれることがある。

以下は、DDDにおける主要な概念である。戦略的設計とも呼ばれる[31]。

同じ言葉（ユビキタス言語）

区切られた文脈内において同じ言葉は同じ意味を持つ。ドメインエキスパートと技術者は、同じ言葉を用いることでドメインに対する共通理解を形成する。ユビキタス言語とも呼ばれる。

区切られた文脈（境界づけられたコンテキスト）

同じ業務領域であっても、文脈が異なれば同じ言葉が異なる意味を持つ場合がある。これに対して、DDDでは区切られた文脈という概念を導入することで文脈によって異なる言葉の意味を明確にする。区切られた文脈は言語学における「意味論的な領域（英語版）」に基づいていると考えることができる[31]。

業務領域

  • 中核の業務領域...
  • 一般的な業務領域
  • 補完的な業務領域

実装方法

DDDにおける戦略を具体的に実装する方法。戦術的設計とも呼ばれる[31]。

トランザクションスクリプト

アクティブレコード

ドメインモデル

ドメインモデルは、区切られた文脈によって明確に定義された言葉に属する業務ロジックを表現するオブジェクトモデル。同じ名前であっても、文脈が異なれば異なる業務ロジックを表現する。ドメインモデルには、値オブジェクトと集約、集約の構成要素としてのエンティティが含まれる[31]。

集約

DDDにおける永続化の単位。一つの集約は、一つまたは複数のエンティティによって構成される。（e.g. Book）

エンティティ

IDによって特定されるオブジェクト。値オブジェクトによって状態が表現される。（e.g. Stock）

値オブジェクト

フィールドの値の組み合わせによって表現されるオブジェクト。値オブジェクトはイミュータブルである。（e.g. BookId）

業務ロジック

ドメインモデルに属するビジネスロジック。

業務サービス

ドメインモデルのみでは自然に表現できない業務ロジックを記述する。



Kinds of models

ドメイン駆動設計におけるモデルには複数の種類がある。例えば、エンティティは属性でなく、識別子によって定義されるオブジェクトである。例えば、ほとんどの航空会社はすべてのフライトにおいて席に対して一意の数字を割り当てている。これは席の識別子である。これとは対照的に、値オブジェクトは属性を持つ一方で、概念的な同一性を持たないイミュータブルなオブジェクトである。例えば、例えば、ある人が名刺を交換する際を例に挙げると、この時名刺を交換する人は名刺の内容（属性）のみに関心があり、名刺一枚一枚を個別に扱うことはない。

Domain-driven design recognizes multiple kinds of models. For example, an entity is an object defined not by its attributes, but its identity. As an example, most airlines assign a unique number to seats on every flight: this is the seat's identity. In contrast, a value object is an immutable object that contains attributes but has no conceptual identity. When people exchange business cards, for instance, they only care about the information on the card (its attributes) rather than trying to distinguish between each unique card.

モデルは、ドメインイベント（過去のある時点で起こった出来事）を定義することもある。ドメインイベントとはドメインエキスパートが重要視するイベントであり、これをイベント履歴式のドメインモデルという。イベント履歴式のドメインモデルでは現在の状態を算出するのに過去のイベントを順番に演算する必要がある。Fowlerは読み取り側のために現在の状態を事前に計算して記録しておくことを、Eager Read Derivationとした。

ドメインモデルは複数のエンティティをルートエンティティによって結びつけ、集約とな

集約外のオブジェクトはルートエンティティへの参照を持つことが許されるが、集約内の他のオブジェクトへの参照を持つことは許されない。集約るーとは集約における変更の一貫性を確認する。例えば、運転手は車のすべてのタイヤを個別にコントロールする必要はなく、ただ車を運転するだけで、この文脈においては集約は車であり、

Models can also define events (something that happened in the past). A domain event is an event that domain experts care about. Models can be bound together by a root entity to become an aggregate. Objects outside the aggregate are allowed to hold references to the root but not to any other object of the aggregate. The aggregate root checks the consistency of changes in the aggregate. Drivers do not have to individually control each wheel of a car, for instance: they simply drive the car. In this context, a car is an aggregate of several other objects (the engine, the brakes, the headlights, etc.).

モデルは、過去に起こった出来事（イベント）を定義することもできる。ドメインイベントとは、ドメインの専門家が重要視するイベントである。モデルは、ルートエンティティによって結びつけられ、アグリゲート（集約）となる。アグリゲート外のオブジェクトはルートへの参照を保持することが許されているが、アグリゲート内の他のオブジェクトへの参照は許されていない。アグリゲートのルートは、アグリゲート内で行われる変更の整合性を確認する役割を果たす。例えば、ドライバーは車の各ホイールを個別に制御する必要はなく、ただ車を運転するだけでよい。この文脈において、車はエンジン、ブレーキ、ヘッドライトなど、他の複数のオブジェクトを集約したものである。

Working with models

In domain-driven design, an object's creation is often separated from the object itself.

A repository, for instance, is an object with methods for retrieving domain objects from a data store (e.g. a database). Similarly, a factory is an object with methods for directly creating domain objects.

When part of a program's functionality does not conceptually belong to any object, it is typically expressed as a service

モデルは、過去に起こった出来事（イベント）を定義することもできる。ドメインイベントとは、ドメインの専門家が関心を持つイベントのことである。モデルは、ルートエンティティによって結び付けられることでアグリゲート（集約）になることができる。アグリゲートの外部にあるオブジェクトは、ルートへの参照を保持することは許されるが、アグリゲート内の他のオブジェクトへの参照を保持することは許されない。アグリゲートのルートは、アグリゲート内の変更が一貫性を保つようチェックする。例えば、ドライバーは車の各ホイールを個別に操作する必要はなく、ただ車を運転するだけである。この文脈では、車はエンジン、ブレーキ、ヘッドライトなどの複数のオブジェクトを集約したものと言える。


DDDのこれらの側面は、ドメインエキスパートと開発者、そしてユーザー間で「同じ言葉（ユビキタス言語）」を共有することを目的としている。ドメインモデルや、システム要件の記述において、「同じ言葉」が用いられる。

「同じ言葉」を用いることは「戦略的設計」「戦術的設計」と並んでDDDの核心的な考え方の一つである。

DDDにおけるドメイン層は、オブジェクト指向の多層アーキテクチャにおける一般的な層の一つである。





これについては私も思っていたところではありますが、labourは名詞の「労働者」であるのに対して、co-operativeは形容詞用法もあります。

労働党はlabourと単に「労働」という名を冠することで単に労働組合の党である以上の包摂性を表しているような気がしていて、co-operative partyも同じく、（結党から歴史が長いのもあり、）協同組合党とするほど、単に協同組合に強く依拠した政党ではないのではないかという所感というか、感覚がありました。（要調査ですが）

こうなると、co-operativeは協同組合を指すと言ったのと矛盾しますね。co-operativeは形容詞における用法を指しており、しかし協同組合主義を根本にしている政党ではある、というようなニュアンスに一旦訂正します。

これらの所感を確かめるために、co-operative partyの公式サイト[32]を改めて参照したのですが、aboutページの紹介を見る限り、思っていたより「協同組合」の色が強いですね。これならば、「協同組合党」とするのもありな気がしてきました。


ドメイン駆動設計（ドメインくどうせっけい、英語: domain-driven design、DDD）は主要なソフトウェア設計手法の一つであり[33]、業務ロジックをドメインエキスパートの知識に基づくドメインに一致させることに主眼を置くものである[34]。DDDは”単一の統一されたモデル”という考え方に反対し、1つの大きなシステムを複数の区切られた文脈に分割する。区切られた文脈は、それぞれが個別のモデルを持つ[35]。

DDDにおいては、ソフトウェアコード（e.g. クラス名、クラスメソッド、クラス変数）における「言葉」や構造をビジネスドメインに一致させる必要がある。例えば、ソフトウェアがローン申請(loan application)を処理する場合、ソフトウェアは「loan application」「customer」といった名前のクラスや「accept offer」「withdraw」といったメソッドを持つことが考えられる。

DDDは以下のような目的に基づく。

  • プロジェクトにおける主な焦点を中核の業務領域（コアドメイン）と業務ロジック（ドメインロジック）のレイヤーに置くこと
  • 複雑な設計をドメインモデルで表現すること
  • 技術者とドメインエキスパートの間にクリエイティブな協働関係を構築し、特定のドメイン問題を扱う概念的なモデルを継続的に洗練させること

DDDという名称は、エリック・エヴァンス（英語版）による著書の中で初めて提唱されたものである[36]。

概要

DDDは大きく戦術的設計と戦略的設計に分けられる。戦略的設計ではあ　DDDの基本的な考え方を含むのは戦略的設計で、同じ言葉、業務領域の分類、区切られた文脈などの概念を含む。戦術的設計では、DDDにおける戦略を達成するために、実際にどのような実装を選択するかという問題を取り扱う[37]。

DDDの考え方には、業務領域を中核の業務領域（コアドメイン）、一般的な業務領域（ジェネリック・サブドメイン）、補完的な業務領域（サブドメイン）に分け、ソフトウェアにおけるそれぞれの部分に最適な実装方法を選択することを含む。一般に、中核の業務領域に戦力を集中させることが重要で、複雑な業務ロジックを含む中核の業務領域には、ドメインモデルや、イベント履歴式のドメインモデルなどの戦術的設計を用いることが適しているとされる[37][38]。

DDDにおいては、事業領域（ドメイン）内において同じ言葉（ユビキタス言語）を使うことによって、ある事業におけるドメインエキスパートとユーザー、エンジニア間で事業活動に対する共通理解を形成する[37][39]。ここで、同じ事業領域内においても、文脈が違えば同じ言葉が異なった意味を持つ場合が存在する。そこで、ドメイン駆動開発では区切られた文脈という概念を導入し、文脈ごとに異なる言葉の意味を明確にする[37]。

DDDは、多くの高水準な概念と実践を明確に示している[40]。もっとも重要なものは、ソフトウェアにおける「ドメイン」であり、これはユーザがプログラムを適用する対象領域を指す。戦術的設計の一つであるドメインモデルパターンにおいては、ソフトウェアの開発者は「ドメインモデル」を構築する。これは特定のドメインのある側面を表現し、ドメインにおける問題を解決するために用いることができるような抽象化のシステムである。

戦略的設計

戦術的設計

ドメインモデルパターンでは、開発者がドメインモデルを純粋で有用な構造として維持するために、通常大量の分離とカプセル化を行う必要がある一方で、保守性などの利点を提供することから、Microsoftは、ドメインに対する共通理解を構築することで明確な利点のある複雑なドメインにのみドメインモデルパターンを導入することを推奨している[41][注釈 1]。


政治・経済・社会・歴史・文芸・言語など、人類の文化全般に関する学問の総称。狭義には、自然科学・社会科学に対して、歴史・哲学・言語などに関する学問をいう。文化科学。じんもんかがく。

人文科学（じんぶんかがく、英語: humanities[42][43][10]）、あるいは人文学（じんぶんがく、英語: humanities[44][45][46]中国語: 人文学科）は、人間社会と文化の側面について研究する学問分野であり、人間が抱く本質的な疑問を含むものを指す。今日、人文学は自然科学、社会科学、形式科学、また応用科学以外のあらゆる分野を指すものとして定義されることが多い[47]。リベラル・アーツの対象としても扱われる[48]。


a


人文科学（じんぶんかがく、英語: humanities[42][49][10]）、あるいは人文学（じんぶんがく、英語: humanities[44][50][51]中国語: 人文学科）は、人間社会と文化の側面について研究する学問分野であり、人間が抱く本質的な疑問を含むものを指す。自然科学、社会科学、形式科学、また応用科学と並ぶ学問の分類であり、人類の文化全般に関する学問の総称である[52]。リベラル・アーツの対象としても扱われる[48]。

人間社会と文化の側面について研究する学問分野であり、人間が抱く本質的な疑問を含むものを指す。今日、

英語における「Humanities」は「人文学」のことを指し、人文学部（人文科学部[53]）はFaculty of Humanitiesと英訳される[54]。

歴史

元々「Humanities（ヒューマニティーズ）」は、ルネサンス期に栄えた人文主義（ヒューマニズム）に由来する[要出典]。明治期以降の流入時に、「humanities」は「人文学」と訳された。学問を二分する分類法が採用されていた時代には、自然科学に対して、現在の社会科学に分類される学問とあわせて「文化科学」と分類されていた[55][56][57][58][59][60][61]。しかし、18世紀から19世紀にかけて政治学・経済学・法学などがいずれも固有の領域を確定したことで、20世紀の半ば以降それらは「社会科学」と呼ばれて分けられるようになり、残りが人文学となった。現代の主流では、学問は自然科学・社会科学・人文科学（人文学）とに分けられる[55]。

ルネサンス期における学者や芸術家はヒューマニストと呼ばれた。当時、「Humanities」という言葉は古典や言語についての研究を指し、宗教や神学に対置されるものとして当時の大学における世俗的なカリキュラムの重要な部分を占めていた[62]。

「Humanities」という言葉は、

The word humanities comes from the Renaissance Latin phrase studia humanitatis, which translates to study of humanity. This phrase was used to refer to the study of classical literature and language, which was seen as an important aspect of a refined education in the Renaissance. In its usage in the early 15th century, the studia humanitatis was a course of studies that consisted of grammar, poetry, rhetoric, history, and moral philosophy, primarily derived from the study of Latin and Greek classics. The word humanitas also gave rise to the Renaissance Italian neologism umanisti, whence "humanist", "Renaissance humanism".

Scholars in the humanities are called humanities scholars or sometimes humanists.[63] The term humanist also describes the philosophical position of humanism, which antihumanist scholars in the humanities reject. Renaissance scholars and artists are also known as humanists. Some secondary schools offer humanities classes usually consisting of literature, history, foreign language, and art.

「人文学」と「人文科学」

Humanities（人文学）という英語は、Science（科学）という意味は含まない。本来的には人文学とのみ呼ばれるべきであるが、自然科学・社会科学と語調を合わせるために人文科学と呼ばれる[要出典]。

安酸の文献によれば、「一言でいえば、「人文学」は本来的にはlearningであり、「人文科学」は文字通りscienceである。」とされ、「人文学」という概念の洗い直しの必要性が指摘されている[64]。

人文科学（じんぶんかがく、英語: humanities[42][65][10], liberal arts[48]）、あるいは人文学（じんぶんがく、英語: humanities[44][66][67]中国語: 人文学科）とは、人間社会と文化の側面について研究する学問分野であり、人間が抱く本質的な疑問を含むものを指す。ルネサンス期において「人文学(=humanities)」という言葉は古典や言語についての研究を指し、宗教や神学に対置されるものとして当時の大学における世俗的なカリキュラムの重要な部分を占めていた。今日、人文学は自然科学、社会科学、形式科学、また応用科学以外のあらゆる分野を指すものとして定義されることが多い[68]。「人文学」では主として批判、推察、解釈的な手法を取り、歴史的な要素を強く含み、科学において主な実証的手法とは区別される。一方で「人文科学」では、

人文科学には、哲学、宗教学、歴史学、言語に関する学問

自然科学・社会科学・形式科学・応用科学とならぶ学問の分類である。自然科学・社会科学が分野として確立したことを受けて作り出された概念であり、両者のいずれにも属さない学問分野の総称である[69][注 1]。人文学部（人文科学部[70]）はFaculty of Humanitiesと英訳される[71]。

Humanities are academic disciplines that study aspects of human society and culture, including certain fundamental questions asked by humans. During the Renaissance, the term 'humanities' referred to the study of classical literature and language, as opposed to the study of religion or 'divinity.' The study of the humanities was a key part of the secular curriculum in universities at the time. Today, the humanities are more frequently defined as any fields of study outside of natural sciences, social sciences, formal sciences (like mathematics), and applied sciences (or professional training).[72] They use methods that are primarily critical, speculative, or interpretative and have a significant historical element[68]—as distinguished from the mainly empirical approaches of science.[68]

The humanities include the studies of philosophy, religion, history, language arts (literature, writing, oratory, rhetoric, poetry, etc.), performing arts (theater, music, dance, etc.), and visual arts (painting, sculpture, photography, filmmaking, etc.).[73]

人文科学とは、人間社会や文化の側面を研究する学問分野であり、人間が抱く根本的な疑問を含むものを指す。ルネサンス期において、「人文科学」という用語は、宗教や「神学」とは対照的に、古典文学および言語の研究を意味していた。当時、大学における世俗的なカリキュラムの重要な一部を占めていたのである。今日では、人文科学は、自然科学、社会科学、形式科学（例えば数学）、応用科学（または専門職訓練）以外のあらゆる研究分野として定義されることが多い。人文科学の方法は、主に批評的、思索的、あるいは解釈的であり、歴史的要素を強く持つものとして特徴づけられる。一方、科学は主に経験的アプローチを採用している点で異なるのである。

Some definitions of the humanities encompass law and religion due to their shared characteristics, such as the study of language and culture.[74] However, these definitions are not universally accepted, as law and religion are often considered professional subjects rather than humanities subjects. Professional subjects, like some social sciences, are sometimes classified as being part of both the liberal arts and professional development education, whereas humanities subjects are generally confined to the traditional liberal arts education. Although sociology, anthropology, archaeology, linguistics and psychology share some similarities with the humanities, these are often considered social sciences. Similarly, disciplines such as finance, business administration, political science, economics, and global studies have closer ties to the social sciences rather than the humanities.

Scholars in the humanities are called humanities scholars or sometimes humanists.[75] The term humanist also describes the philosophical position of humanism, which antihumanist scholars in the humanities reject. Renaissance scholars and artists are also known as humanists. Some secondary schools offer humanities classes usually consisting of literature, history, foreign language, and art.

Human disciplines like history and language mainly use the comparative method[76] and comparative research. Other methods used in the humanities include hermeneutics, source criticism, esthetic interpretation, and speculative reason.



人文科学（じんぶんかがく、英語: humanities[42][77][10]）、あるいは人文学（じんぶんがく、英語: humanities[44][78][79]中国語: 人文学科）は、人間社会と文化の側面について研究する学問分野であり、人間が抱く本質的な疑問を含むものを指す。自然科学、社会科学、形式科学、また応用科学と並ぶ学問の分類であり、人類の文化全般に関する学問の総称である[80]。リベラル・アーツの対象としても扱われる[48]。

人間社会と文化の側面について研究する学問分野であり、人間が抱く本質的な疑問を含むものを指す。今日、

英語における「Humanities」は「人文学」のことを指し、人文学部（人文科学部[81]）はFaculty of Humanitiesと英訳される[82]。

歴史

元々「Humanities（ヒューマニティーズ）」は、ルネサンス期に栄えた人文主義（ヒューマニズム）に由来する[要出典]。明治期以降の流入時に、「humanities」は「人文学」と訳された。学問を二分する分類法が採用されていた時代には、自然科学に対して、現在の社会科学に分類される学問とあわせて「文化科学」と分類されていた[83][84][85][86][87][88][89]。しかし、18世紀から19世紀にかけて政治学・経済学・法学などがいずれも固有の領域を確定したことで、20世紀の半ば以降それらは「社会科学」と呼ばれて分けられるようになり、残りが人文学となった。現代の主流では、学問は自然科学・社会科学・人文科学（人文学）とに分けられる[83]。

ルネサンス期における学者や芸術家はヒューマニストと呼ばれた。当時、「Humanities」という言葉は古典や言語についての研究を指し、宗教や神学に対置されるものとして当時の大学における世俗的なカリキュラムの重要な部分を占めていた[90]。

「Humanities」という言葉は、

The word humanities comes from the Renaissance Latin phrase studia humanitatis, which translates to study of humanity. This phrase was used to refer to the study of classical literature and language, which was seen as an important aspect of a refined education in the Renaissance. In its usage in the early 15th century, the studia humanitatis was a course of studies that consisted of grammar, poetry, rhetoric, history, and moral philosophy, primarily derived from the study of Latin and Greek classics. The word humanitas also gave rise to the Renaissance Italian neologism umanisti, whence "humanist", "Renaissance humanism".

Scholars in the humanities are called humanities scholars or sometimes humanists.[91] The term humanist also describes the philosophical position of humanism, which antihumanist scholars in the humanities reject. Renaissance scholars and artists are also known as humanists. Some secondary schools offer humanities classes usually consisting of literature, history, foreign language, and art.

「人文学」と「人文科学」

Humanities（人文学）という英語は、Science（科学）という意味は含まない。本来的には人文学とのみ呼ばれるべきであるが、自然科学・社会科学と語調を合わせるために人文科学と呼ばれる[要出典]。

安酸の文献によれば、「一言でいえば、「人文学」は本来的にはlearningであり、「人文科学」は文字通りscienceである。」とされ、「人文学」という概念の洗い直しの必要性が指摘されている[92]。


ドメイン駆動設計（ドメインくどうせっけい、英語: domain-driven design、DDD）は主要なソフトウェア設計手法の一つであり[93]、ドメインエキスパートの言葉に基づき、ドメインにおけるプロセスやルールをよく表現したドメインモデルを構築し、それに基づいてソフトウェア開発を行うことに主眼を置くものである[94][95][96]。

DDDでは区切られた文脈ごとに一つの言葉に対して一つの業務ロジックを与える。区切られた文脈内においては、同じ言葉は同じ意味を持ち、すなわち同じ業務ロジックを持つことになる。区切られた文脈を適当に設計することが、ドメイン駆動設計の核心的な考え方の一つである。

DDDという名称は、エリック・エヴァンス（英語版）による著書の中で初めて提唱されたものである[97]。

概要

DDDは大きく戦術的設計と戦略的設計に分けられる[誰?]。戦略的設計では、同じ言葉、区切られた文脈という概念を導入し、事業活動をその性質によって複数の業務領域に分類する。事業活動は、中核の業務領域（コアドメイン）、一般的な業務領域（ジェネリック・サブドメイン）、補完的な業務領域（サブドメイン）に分類される[98]。

戦術的設計では、DDDにおける戦略を達成するために、具体的にどのように業務ロジックを表現し、ソフトウェアを実装するかを扱う。業務ロジックの表現方法としては、トランザクションスクリプト、アクティブレコード、ドメインモデル、イベント履歴式のドメインモデルなどが挙げられる[98]。

戦略的設計

言葉の意味と文脈

DDDにおいては、ドメインエキスパートと技術者間で同じ言葉を用いることによって、業務に対する共通理解を形成する[98][99]。ただし、同じ事業領域内においても、背景が異なれば異なった意味を持つ言葉が存在する。この曖昧さを解消するために、DDDでは区切られた文脈という概念を導入する[98]。

同じ言葉（ユビキタス言語）

同じ言葉、あるいはユビキタス言語（英語: Ubiquitous language）とは、同じ言葉を使うことでドメインエキスパートと技術者間の効率的な意思伝達を促す、DDDにおける戦略的手法のことである。DDDでは、技術者がドメインエキスパートと協力しながら同じ言葉を育て、特定のドメイン問題を扱うモデルの継続的な洗練を目指す[98]。

ソフトウェアコード（e.g. クラス名、クラスメソッド、クラス変数）における言葉や構造はビジネスドメインに一致する。例えば、ソフトウェアがローン申請(loan application)を処理する場合、ソフトウェアは「loan application」「customer」といった名前のクラスや「accept offer」「withdraw」といったメソッドを持つことが考えられる。

区切られた文脈（境界づけられたコンテキスト）

区切られた文脈、あるいは境界づけられたコンテキスト（英語: Bounded context）とは、同じ言葉に同じ意味を適用できる範囲のことである。区切られた文脈は、ソフトウェア設計の観点で、ソフトウェア技術者が決定する[98]。

マーティン・ファウラーは、ドメインが大きくなるにしたがって、統一された単一のモデルを構築することは難しくなるとしている[100]。これは、事業領域において、同じ言葉でも文脈によって異なる意味を持つ場合が出てくるためである[注釈 2]。

計算機科学における難題は二つしかない。それはキャッシュの無効化と、命名である。ー フィル・カールトン[101]

区切られた文脈は言語学における「意味論的な領域（英語版）」に基づいているとされる。意味論的な領域とは、同じ言葉が同じ意味で使われる範囲のことを指し、例えば「トマト」が植物学的な文脈では「果実」である一方で、法的[注釈 3]な文脈では「野菜」であるようなことが挙げられる[98]。

業務領域の分類

DDDにおいて、ソフトウェアは中核の業務領域と、一般的な業務領域、補完的な業務領域に分けられる。DDDにおける重要かつ主要な目的の一つは、戦力を中核の業務領域に集中させることであるとされる[102]。

あるソフトウェアにおいて一般的な業務領域であっても、

中核の業務領域

中核の業務領域（英語: Core subdomain）は、プロジェクトのコアとなる複雑で重要なロジックを含む部分である。ドメインモデルなどの複雑な業務ロジックを扱うためのデザインパターン（戦術的設計）を選択することが考えられる。事業において戦略上強みとなる部分であり、頻繁な変更が考えられる[98]。

一般的な業務領域

一般的な業務領域（英語: Generic subdomain）はどのソフトウェアにおいても基本的にアプローチが変わらないような部分であり、したがって外部のソフトウェアやライブラリを活用することが考えられるとされる[98]。

補完的な業務領域

補完的な業務領域（英語: Supporting subdomain）は、事業活動を支えるものの、競争優位を生み出さない部分である。補完的な業務領域のロジックは単純で、トランザクションスクリプトやアクティブレコードなどの簡易なデザインパターンを選択することが適しているとされる[98]。

戦術的設計

戦術的設計では、具体的にどのようにソフトウェアを実装するかという問題を取り扱う。以下はDDDにおける主要な技術方式である。

業務ロジックの表現方法

トランザクションスクリプト

トランザクションスクリプトは、手続的に操作を記述する業務ロジックの表現方法である[98]。

アクティブレコードパターン

アクティブレコードでは、オブジェクトがデータベースにおけるテーブルあるいはビューにおけるレコードの一行を表現する。アクティブレコードパターンにおいても業務ロジックは手続的に記述されるが、DBへの接続はアクティブレコードモデルを通して行われる[98]。

アクティブレコードパターンを実装したものとして、Ruby on RailsにおけるActive Recordがある。

ドメインモデルパターン

ドメインモデルは、業務ロジックとデータの両方を一体化させた、事業活動を表現するオブジェクトモデルである[103]。ドメインモデルは集約、値オブジェクト、ドメインイベント、ドメインサービスによって表現される[98]。

ドメインモデルにおいて、業務ロジックは集約や値オブジェクトに属するものとして定義されるのに加え、それらに定義することが不自然であったり、集約を跨いだ業務ロジックについては、ドメインサービスによって表現される[98]。

複雑な業務ロジックを含む中核の業務領域における業務ロジックの実装には、一般にドメインモデルパターンや、イベント履歴式のドメインモデルが適しているとされている[98][102]。

ドメインモデルパターンでは、開発者がドメインモデルを純粋で有用な構造として維持するためには、通常大量の分離とカプセル化を行う必要がある一方で、保守性などの利点を提供するため、Microsoftは、ドメインに対する共通理解を構築することで明確な利点のある複雑なドメインにのみドメインモデルパターンを導入することを推奨している[注釈 4]。

ドメインモデルが持つべきドメイン知識がドメインモデルの外に書かれており、ドメインモデルが業務知識を持たなくなってしまう状態を「ドメインモデル貧血症」と呼ぶことがある[98][104]。

イベント履歴式のドメインモデル

イベント履歴式のドメインモデルでは、集約の状態変化を一連のドメインイベントで表現する。ドメインモデルパターンでは集約の状態を永続化するのに対し、イベント履歴式のドメインモデルでは集約の状態の変化を表すドメインイベントを永続化する[98]。

このパターンにおいては過去のある時点においての状態を得ることができるというメリットがある一方で、現在の状態を再現するために計算が必要になるというデメリットがある。これについては、CQRSパターンを用いて集約の状態に変更がありコマンド実行モデルを利用してテーブルが更新されるたびに最新の状態を投影したキャッシュとしてのビューを更新し、読み込みモデルからはこちらを参照することで対応できるとされる[98][101]。

アーキテクチャ方式

階層化アーキテクチャ

ソフトウェアの階層化は情報技術において一般的な考え方の一つである。例えば、情報通信の分野においては、OSI参照モデルが階層化アーキテクチャとして挙げられる。

アプリケーションレベルのソフトウェアアーキテクチャにおいては、以下に示すようないくつかのアーキテクチャパターンが知られている。

レイヤードアーキテクチャ

古典的な三層レイヤードアーキテクチャでは、技術的な関心ごとに基づいて、アプリケーションをプレゼンテーション層、ドメインロジック層、データアクセス層の三層に分ける[98][105]。

ポートとアダプタ方式

ポートとアダプタ方式では、古典的なレイヤードアーキテクチャに対して、依存性の逆転を意識する。この方式に基づいたアーキテクチャモデルとしては、オニオンアーキテクチャ、クリーンアーキテクチャ、ヘキサゴナルアーキテクチャ（英語版）が知られる[98]。

これらのアーキテクチャでは、依存性の逆転を行うことによって、古典的アーキテクチャにおけるドメインロジック層がデータアクセス層に依存することを回避する。これは、データアクセス層の具体的な実装の知識はドメインロジックに属するものではないためである。これらのアーキテクチャにおいてはドメインロジックを含むドメインモデルアーキテクチャのが中心に位置し、内層は外層に依存しない[98]。

依存性逆転の原則

→詳細は「依存性逆転の原則」を参照

CQRS（コマンドクエリ責任分離）

→詳細は「コマンドクエリ責任分離」を参照

ドメインモデルの構成要素

ドメインモデルは集約とそれを構成するエンティティ、値オブジェクトに加え、ドメインサービスといった要素からなる[98]。集約はドメインモデルの永続化におけるトランザクションの単位[98]であり、複数のエンティティを持つルートエンティティが集約として扱われる。エンティティはIDによって同一性が識別され、エンティティや値オブジェクトによって状態が表現されるミュータブルなオブジェクトである。一方で値オブジェクトは属性の組み合わせによって同一性が識別される[注釈 5]イミュータブルなオブジェクトである[98]。

ドメインサービスは、集約や値オブジェクトに実装することが不自然な業務ロジックを実装するためのステートレスなオブジェクトである[98]。

関連項目

  • コードベース - ドメイン駆動設計は、業務ロジックにおけるコードベースを効率的に管理するための設計手法である。
  1. ^ 出典ではドメインモデルパターンについてではなく、DDDに対しての記述となるが、DDDにおけるドメインモデルパターンを指しての記述と考えられる。
  2. ^ 例えば「見込み客」という言葉は、ある文脈においては「自社の製品に興味を持った」という意味であり、他のある文脈によっては「営業プロセスにおいて取り組むべき対象」という意味で用いられ得る[6]。
  3. ^ アメリカ法
  4. ^ 原文で導入を勧めているのは「Domain Driven Desing」だが、原文ではDDDを「ドメインエキスパートの言葉で表現されるドメインモデルを定義する」ものとしているため、ドメインモデルに対しての記述であると考えられる。
  5. ^ 同じ値を持つオブジェクトは同じものとして扱われる。
  1. ^ Table of Electoral Systems Worldwide Archived 2017-05-23 at the Wayback Machine. IDEA
  2. ^ “英国における２０１１年国民投票と選挙制度改革”. jstage. 2024年7月24日閲覧。
  3. ^ a b Table of Electoral Systems Worldwide Archived 2017-05-23 at the Wayback Machine. IDEA
  4. ^ Table of Electoral Systems Worldwide Archived 2017-05-23 at the Wayback Machine. IDEA
  5. ^ Fenster, Mark (1983). “Approval Voting: Do Moderates Gain?”. Political Methodology 9 (4): 355–376. JSTOR 25791202. https://www.jstor.org/stable/25791202 2024年5月24日閲覧。. 
  6. ^ “What is Approval Voting?”. Election Science. The Center for Election Science. 2024年5月24日閲覧。 “Voters can vote for as many candidates as they want. The votes are tallied, and the candidate with the most votes wins!”
  7. ^ Sri Lanka: Election for President IFES
  8. ^ Table of Electoral Systems Worldwide Archived 2017-05-23 at the Wayback Machine. IDEA
  9. ^ Ecuador: Election for President Archived 2016-12-24 at the Wayback Machine. IFES
  10. ^ a b c d e f g h i Vlad Khononov 著、増田亨・綿引琢磨 訳『ドメイン駆動設計をはじめよう』株式会社オライリー・ジャパン、2024年7月18日、xx, 44頁。  引用エラー: 無効な <ref> タグ; name ":0"が異なる内容で複数回定義されています
  11. ^ a b c d e f Bjørner, Dines (2006). “The Triptych of Software Engineering” (英語). Software Engineering 3 – Domains, Requirements, and Software Design (book). I. Springer Verlag. p. 9. ISBN 978-3-540-33653-2. https://www.springer.com/us/book/9783540211518 2016年12月19日閲覧。 
  12. ^ a b Andrew Powell-Morse (April 21, 2017). “Domain-Driven Design - What is it and how do you use it?”. May 2, 2020閲覧。
  13. ^ a b Eric Evans (2015年). “Domain Driven Design Reference: Definitions and Pattern Summaries”. domainlanguage.com. May 2, 2020閲覧。
  14. ^ Bjørner, Dines (2006). “The Tryptych of Software Engineering” (English). Software Engineering 3 – Domains, Requirements, and Software Design (book). I. Springer Verlag. p. 9. ISBN 978-3-540-33653-2. https://www.springer.com/us/book/9783540211518 2016年12月19日閲覧。 
  15. ^ a b c d e f g Vlad Khononov 著、増田亨・綿引琢磨 訳『ドメイン駆動設計をはじめよう』株式会社オライリー・ジャパン、2024年7月18日、xx, 44頁。 
  16. ^ a b Bjørner, Dines (2006). “The Triptych of Software Engineering” (英語). Software Engineering 3 – Domains, Requirements, and Software Design (book). I. Springer Verlag. p. 9. ISBN 978-3-540-33653-2. https://www.springer.com/us/book/9783540211518 2016年12月19日閲覧。 
  17. ^ Andrew Powell-Morse (April 21, 2017). “Domain-Driven Design - What is it and how do you use it?”. May 2, 2020閲覧。
  18. ^ Eric Evans (2015年). “Domain Driven Design Reference: Definitions and Pattern Summaries”. domainlanguage.com. May 2, 2020閲覧。
  19. ^ a b c d e Schermers, Henry G.; Blokker, Niels M. (2011). International Institutional Law: Unity Within Diversity (5 ed.). Martinus Nijhoff Publishers. ISBN 978-9004187986. https://books.google.com/books?id=OMXToQLp21UC&q=relative+majority 
  20. ^ a b Dougherty, Keith L.; Edward, Julian (2010). “The Properties of Simple Vs. Absolute Majority Rule: Cases Where Absences and Abstentions Are Important”. Journal of Theoretical Politics 22: 85–122. doi:10.1177/0951629809347557. https://journals.sagepub.com/doi/abs/10.1177/0951629809347557?journalCode=jtpa. 
  21. ^ “General Assembly of the United Nations - Rules of procedure - XII. Plenary Meetings”. United Nations. 2024年8月10日閲覧。
  22. ^ “In Parliament, which votes require a simple majority and which votes require an absolute majority? - Parliamentary Education Office”. 2024年8月10日閲覧。
  23. ^ “選挙用語集”. アメリカ合衆国選挙支援委員会. 2024年8月10日閲覧。
  24. ^ a b “Liberalism against Popurism”. University of Maryland. 2024年8月10日閲覧。
  25. ^ Millet, Scott; Tune, Nick (2015). Patterns, Principles, and Practices of Domain-Driven Design. Indianapolis: Wrox. ISBN 978-1-118-71470-6 
  26. ^ Vernon, Vaughn (2013). Implementing Domain-Driven Design. Upper Sadle River, NJ: Addison-Wesley. p. 3. ISBN 978-0-321-83457-7 
  27. ^ Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional. (2003). ISBN 978-0321125217 
  28. ^ Microsoft Application Architecture Guide, 2nd Edition. Retrieved from http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle.
  29. ^ Evans, Eric (2004). Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison-Wesley. ISBN 978-032-112521-7. http://dddcommunity.org/book/evans_2003/ 2012年8月12日閲覧。 
  30. ^ Evans, Eric (August 22, 2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison-Wesley. ISBN 978-032-112521-7. http://dddcommunity.org/book/evans_2003/ 2012年8月12日閲覧。 
  31. ^ a b c d e f g h Vlad Khononov 著、増田亨・綿引琢磨 訳『ドメイン駆動設計をはじめよう』株式会社オライリー・ジャパン、2024年7月18日、xx, 44頁。 
  32. ^ “About the Party” (英語). Co-operative Party. 2024年8月31日閲覧。
  33. ^ Millet, Scott; Tune, Nick (2015). Patterns, Principles, and Practices of Domain-Driven Design. Indianapolis: Wrox. ISBN 978-1-118-71470-6 
  34. ^ Vernon, Vaughn (2013). Implementing Domain-Driven Design. Upper Sadle River, NJ: Addison-Wesley. p. 3. ISBN 978-0-321-83457-7 
  35. ^ Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional. (2003). ISBN 978-0321125217 
  36. ^ Evans, Eric (2004). Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison-Wesley. ISBN 978-032-112521-7. http://dddcommunity.org/book/evans_2003/ 2012年8月12日閲覧。 
  37. ^ a b c d Vlad Khononov 著、増田亨・綿引琢磨 訳『ドメイン駆動設計をはじめよう』株式会社オライリー・ジャパン、2024年7月18日、xx, 44頁。 
  38. ^ digitalsoul (2011年4月10日). “戦略的設計入門”. Digital Romanticism. 2024年8月27日閲覧。
  39. ^ “bliki: Ubiquitous Language”. martinfowler.com. 2024年8月27日閲覧。
  40. ^ Evans, Eric (August 22, 2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison-Wesley. ISBN 978-032-112521-7. http://dddcommunity.org/book/evans_2003/ 2012年8月12日閲覧。 
  41. ^ Microsoft Application Architecture Guide, 2nd Edition. Retrieved from http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle.
  42. ^ a b c d JST科学技術用語日英対訳辞書. “「人文科学」の英語・英語例文・英語表現 - Weblio和英辞書”. ejje.weblio.jp. Weblio英和辞書. GRASグループ株式会社. 2022年12月22日閲覧。 “cultural science; humanities”
  43. ^ “「人文」の英語・英語例文・英語表現 - Weblio和英辞書”. ejje.weblio.jp. 2024年4月18日閲覧。
  44. ^ a b c d JMdict. “「人文学」の英語・英語例文・英語表現”. ejje.weblio.jp. Weblio和英辞書. GRASグループ株式会社. 2022年12月22日閲覧。 “humanities; arts”
  45. ^ https://ura.sec.tsukuba.ac.jp/archives/6244
  46. ^ https://sy.rikkyo.ac.jp/web/preview.php?nendo=2023&kodo_2=HB004
  47. ^ "Humanity" 2.b, Oxford English Dictionary 3rd Ed. (2003)
  48. ^ a b c d 南出 & 中邑 2023, p. 1196.
  49. ^ “「人文」の英語・英語例文・英語表現 - Weblio和英辞書”. ejje.weblio.jp. 2024年4月18日閲覧。
  50. ^ https://ura.sec.tsukuba.ac.jp/archives/6244
  51. ^ https://sy.rikkyo.ac.jp/web/preview.php?nendo=2023&kodo_2=HB004
  52. ^ "Humanity" 2.b, Oxford English Dictionary 3rd Ed. (2003)
  53. ^ https://www.meiji.ac.jp/cip/recruitment/mkmht0000001pwc1-att/401003.pdf
  54. ^ “Faculty of Humanities | Study at NU |” (英語). NIIGATA UNIVERSITY. 2024年4月18日閲覧。
  55. ^ a b 岸本 美緖 編『宗教と学問』 11巻、弘文堂〈歴史学事典〉、2004年2月、382頁。ISBN 4-335-21041-8。OCLC 959681322。 
  56. ^ 「文化科学」『日本大百科全書(ニッポニカ)』。https://kotobank.jp/word/%E6%96%87%E5%8C%96%E7%A7%91%E5%AD%A6#E6.97.A5.E6.9C.AC.E5.A4.A7.E7.99.BE.E7.A7.91.E5.85.A8.E6.9B.B8.28.E3.83.8B.E3.83.83.E3.83.9D.E3.83.8B.E3.82.AB.29。コトバンクより2023年1月24日閲覧。 
  57. ^ 「文化科学」『精選版 日本国語大辞典』。https://kotobank.jp/word/%E6%96%87%E5%8C%96%E7%A7%91%E5%AD%A6#E7.B2.BE.E9.81.B8.E7.89.88.20.E6.97.A5.E6.9C.AC.E5.9B.BD.E8.AA.9E.E5.A4.A7.E8.BE.9E.E5.85.B8。コトバンクより2023年1月24日閲覧。 
  58. ^ 「文化科学」『ブリタニカ国際大百科事典 小項目事典』。https://kotobank.jp/word/%E6%96%87%E5%8C%96%E7%A7%91%E5%AD%A6#E3.83.96.E3.83.AA.E3.82.BF.E3.83.8B.E3.82.AB.E5.9B.BD.E9.9A.9B.E5.A4.A7.E7.99.BE.E7.A7.91.E4.BA.8B.E5.85.B8.20.E5.B0.8F.E9.A0.85.E7.9B.AE.E4.BA.8B.E5.85.B8。コトバンクより2023年1月24日閲覧。 
  59. ^ 「文化科学」『デジタル大辞泉』。https://kotobank.jp/word/%E6%96%87%E5%8C%96%E7%A7%91%E5%AD%A6#E3.83.87.E3.82.B8.E3.82.BF.E3.83.AB.E5.A4.A7.E8.BE.9E.E6.B3.89。コトバンクより2023年1月24日閲覧。 
  60. ^ 「文化科学」『世界大百科事典 第２版』。https://kotobank.jp/word/%E6%96%87%E5%8C%96%E7%A7%91%E5%AD%A6#E4.B8.96.E7.95.8C.E5.A4.A7.E7.99.BE.E7.A7.91.E4.BA.8B.E5.85.B8.20.E7.AC.AC.EF.BC.92.E7.89.88。コトバンクより2023年1月24日閲覧。 
  61. ^ 「世界大百科事典内の文化科学の言及」『世界大百科事典 第２版』。https://kotobank.jp/word/%E6%96%87%E5%8C%96%E7%A7%91%E5%AD%A6#sekai_refs。コトバンクより2023年1月24日閲覧。 
  62. ^ "humanism." Encyclopædia Britannica. Encyclopædia Britannica Online. Encyclopædia Britannica Inc., 2012. Web. 11 Apr. 2012. [1] Archived 2015-06-05 at the Wayback Machine.
  63. ^ "Humanist" Oxford English Dictionary. Oed.com Archived 2020-06-16 at the Wayback Machine.
  64. ^ “現在、あらためて≪人文学≫を問う”. 2024年9月2日閲覧。
  65. ^ “「人文」の英語・英語例文・英語表現 - Weblio和英辞書”. ejje.weblio.jp. 2024年4月18日閲覧。
  66. ^ https://ura.sec.tsukuba.ac.jp/archives/6244
  67. ^ https://sy.rikkyo.ac.jp/web/preview.php?nendo=2023&kodo_2=HB004
  68. ^ a b c "Humanity" 2.b, Oxford English Dictionary 3rd Ed. (2003)
  69. ^ 岸本 美緖 編『宗教と学問』 11巻、弘文堂〈歴史学事典〉、2004年2月、382頁。ISBN 4-335-21041-8。OCLC 959681322。 
  70. ^ https://www.meiji.ac.jp/cip/recruitment/mkmht0000001pwc1-att/401003.pdf
  71. ^ “Faculty of Humanities | Study at NU |” (英語). NIIGATA UNIVERSITY. 2024年4月18日閲覧。
  72. ^ Oxford English Dictionary 3rd Edition 
  73. ^ “Arts and Humanities Majors and Degrees – BigFuture” (英語). bigfuture.collegeboard.org. 2023年12月13日閲覧。
  74. ^ “What are the Humanities”. Stanford University Humanities Center (16 December 2013). 2014年3月29日時点のオリジナルよりアーカイブ。16 July 2016閲覧。
  75. ^ "Humanist" Oxford English Dictionary. Oed.com Archived 2020-06-16 at the Wayback Machine.
  76. ^ Wallace and Gach (2008) p.28 Archived 2022-12-06 at the Wayback Machine.
  77. ^ “「人文」の英語・英語例文・英語表現 - Weblio和英辞書”. ejje.weblio.jp. 2024年4月18日閲覧。
  78. ^ https://ura.sec.tsukuba.ac.jp/archives/6244
  79. ^ https://sy.rikkyo.ac.jp/web/preview.php?nendo=2023&kodo_2=HB004
  80. ^ "Humanity" 2.b, Oxford English Dictionary 3rd Ed. (2003)
  81. ^ https://www.meiji.ac.jp/cip/recruitment/mkmht0000001pwc1-att/401003.pdf
  82. ^ “Faculty of Humanities | Study at NU |” (英語). NIIGATA UNIVERSITY. 2024年4月18日閲覧。
  83. ^ a b 岸本 美緖 編『宗教と学問』 11巻、弘文堂〈歴史学事典〉、2004年2月、382頁。ISBN 4-335-21041-8。OCLC 959681322。 
  84. ^ 「文化科学」『日本大百科全書(ニッポニカ)』。https://kotobank.jp/word/%E6%96%87%E5%8C%96%E7%A7%91%E5%AD%A6#E6.97.A5.E6.9C.AC.E5.A4.A7.E7.99.BE.E7.A7.91.E5.85.A8.E6.9B.B8.28.E3.83.8B.E3.83.83.E3.83.9D.E3.83.8B.E3.82.AB.29。コトバンクより2023年1月24日閲覧。 
  85. ^ 「文化科学」『精選版 日本国語大辞典』。https://kotobank.jp/word/%E6%96%87%E5%8C%96%E7%A7%91%E5%AD%A6#E7.B2.BE.E9.81.B8.E7.89.88.20.E6.97.A5.E6.9C.AC.E5.9B.BD.E8.AA.9E.E5.A4.A7.E8.BE.9E.E5.85.B8。コトバンクより2023年1月24日閲覧。 
  86. ^ 「文化科学」『ブリタニカ国際大百科事典 小項目事典』。https://kotobank.jp/word/%E6%96%87%E5%8C%96%E7%A7%91%E5%AD%A6#E3.83.96.E3.83.AA.E3.82.BF.E3.83.8B.E3.82.AB.E5.9B.BD.E9.9A.9B.E5.A4.A7.E7.99.BE.E7.A7.91.E4.BA.8B.E5.85.B8.20.E5.B0.8F.E9.A0.85.E7.9B.AE.E4.BA.8B.E5.85.B8。コトバンクより2023年1月24日閲覧。 
  87. ^ 「文化科学」『デジタル大辞泉』。https://kotobank.jp/word/%E6%96%87%E5%8C%96%E7%A7%91%E5%AD%A6#E3.83.87.E3.82.B8.E3.82.BF.E3.83.AB.E5.A4.A7.E8.BE.9E.E6.B3.89。コトバンクより2023年1月24日閲覧。 
  88. ^ 「文化科学」『世界大百科事典 第２版』。https://kotobank.jp/word/%E6%96%87%E5%8C%96%E7%A7%91%E5%AD%A6#E4.B8.96.E7.95.8C.E5.A4.A7.E7.99.BE.E7.A7.91.E4.BA.8B.E5.85.B8.20.E7.AC.AC.EF.BC.92.E7.89.88。コトバンクより2023年1月24日閲覧。 
  89. ^ 「世界大百科事典内の文化科学の言及」『世界大百科事典 第２版』。https://kotobank.jp/word/%E6%96%87%E5%8C%96%E7%A7%91%E5%AD%A6#sekai_refs。コトバンクより2023年1月24日閲覧。 
  90. ^ "humanism." Encyclopædia Britannica. Encyclopædia Britannica Online. Encyclopædia Britannica Inc., 2012. Web. 11 Apr. 2012. [2] Archived 2015-06-05 at the Wayback Machine.
  91. ^ "Humanist" Oxford English Dictionary. Oed.com Archived 2020-06-16 at the Wayback Machine.
  92. ^ “現在、あらためて≪人文学≫を問う”. 2024年9月2日閲覧。
  93. ^ Millet, Scott; Tune, Nick (2015). Patterns, Principles, and Practices of Domain-Driven Design. Indianapolis: Wrox. ISBN 978-1-118-71470-6 
  94. ^ “bliki: Domain Driven Design”. martinfowler.com. 2024年9月4日閲覧。
  95. ^ “Microsoft – Cloud, Computers, Apps & Gaming” (英語). www.microsoft.com. 2022年8月23日閲覧。
  96. ^ Vernon, Vaughn (2013). Implementing Domain-Driven Design. Upper Sadle River, NJ: Addison-Wesley. p. 3. ISBN 978-0-321-83457-7 
  97. ^ Evans, Eric (2004). Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison-Wesley. ISBN 978-032-112521-7. http://dddcommunity.org/book/evans_2003/ 2012年8月12日閲覧。 
  98. ^ a b c d e f g h i j k l m n o p q r s t u v w x y Vlad Khononov 著、増田亨・綿引琢磨 訳『ドメイン駆動設計をはじめよう』株式会社オライリー・ジャパン、2024年7月18日、xx, 44頁。 
  99. ^ “bliki: Ubiquitous Language”. martinfowler.com. 2024年8月27日閲覧。
  100. ^ “bliki: Bounded Context”. martinfowler.com. 2024年9月4日閲覧。
  101. ^ a b “CQRS – Simple architecture | Kariera Future Processing” (ポーランド語). kariera.future-processing.pl (2015年4月10日). 2024年9月3日閲覧。
  102. ^ a b digitalsoul (2011年4月10日). “戦略的設計入門”. Digital Romanticism. 2024年8月27日閲覧。
  103. ^ “Domain Model”. martinfowler.com. 2024年9月4日閲覧。
  104. ^ “ドメインモデル貧血症について質問したいです。|新たな発想を生み出す質問箱 Querie.me”. Querie.meで質問が回答されました. 2024年9月4日閲覧。
  105. ^ “3層アーキテクチャーとは | IBM”. www.ibm.com (2023年3月21日). 2024年9月4日閲覧。


引用エラー: 「注」という名前のグループの <ref> タグがありますが、対応する <references group="注"/> タグが見つかりません

「https://ja.wikipedia.org/w/index.php?title=利用者:Br3kyokyo/sandbox&oldid=101724998」から取得