外部から隠蔽しました。セッターを実装しなくても。このような実装は防ぐことができますが、ほかのファイルが増えていくにつれて、管理できなくなり実装してしまう可能性は十分にあります。更新できるので、ドメインオブジェクトのルールを簡単に破れることになります。更新を禁止するフィールドは周知が必要になるので、同様に人の目視で守る必要があります。作成する必要が生まれるため、管理が煩雑になります。そのためやめておいたほうがよいでしょう。構成を調べているうちに思った完全な主観です。検討違いのことを言っている可能性があります。ディレクトリ構成を深くするパターンはみたことない気がしますし、推奨される構成もシンプルかつフラットに作成する印象が強いです。アーキテクチャを導入すると、レイヤやドメイン間でドメインオブジェクトの型を参照するために、すべてのフィールドを公開する場合もあり、いたずらに複雑化させてしまいます。そのためフラットに書いた方が良かったりします。内でドメインルールを破るオブジェクトの更新が可能になります。らしい書き方ではない次第です。以下のソースコードは「実践ドメイン駆動設計」のサンプルコードです。構成を区切っていくので、ある程度深くなっていきます。原則を守りながらアーキテクチャの責務が成立します。区切って、構造体とフィールドの公開と非公開を適切にすれば、ある程度は保証されます。らしくなさそうという印象もあるため、理由に書かきました。式で網羅性を担保できないなど)さらに理由が増えていくと考えています。最初にも書いた通り、要約すると人の目視で守ることが多すぎると感じたため相性が悪いと考えています。原則を守るために、静的型づけ言語を当たり前のように使われていると考えています。原則を落とし込めていないと思いました。原則を守れます(実装コストが高くなるという問題点がありますが)。採用するメリットを優先すれば実践できます。性質に合わせる必要があります。これは、ドメインが技術に引っ張られることですので、やはり相性が悪い印象です。原則に厳密に沿った実装を目指すのであれば、Java、Kotlin、C#といったオブジェクト指向言語の方が相性良さそうだと考えています。Functional」では、関数型言語(F#)を用いてを実践しています。実践したバイブルが存在していないだけの可能性があります。同様に、自分の考察が悪いだけの可能性がありますので、ぜひコメントにて指摘のほどお願いします。2022/06/19記事のタイトルに興味を惹かれ、読ませていただきました。着眼点、とても勉強になります。貴重な記事をありがとうございます。私はGo言語はまだ詳しくないのですが、こういったシーンでinterfaceを使うのではないかと、理解しています。コードを書いてみたのですが、interfaceを使えば守ってくれることにならないでしょうか。駆使すれば、このように可能な限り不変にできるんですね。非常に参考になります。手元でも確認したかぎり、確かに不変にできそうです。提案していただいた実装方法で、DDDの実装を深堀できていないため、正しい意見なのかわかりませんが気になった点が1点あります。値オブジェクトやエンティティのように値に型を持たせたい場合に、Goらしい書き方なのかどうか気になりました。値を一つ要素にまとめるときには構造体を使う印象です。するときなどなので、値に型を持たせるパターンを拝見したことがなく気になりました。適用するとこうなるのかもしれません。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。