Re: How far do we take exposing aggregate internals?
"Jorge Branco [email protected] [domaindrivendesign]" <[email protected]> Thu, 7 May 2015 07:05:26 +0100
| Newsgroups | gmane.comp.programming.domain-driven-design |
|---|---|
| Message-ID | <CAMfCbE_0W6dndWxz70G4PTBdFf1Ws2VWzZ+QQPp+FyfmNirpkA@mail.gmail.com> |
Not really. You just want to make sure the internal state of the aggregate roots is not messed up by the outside world, i.e., it never gets into an inconsistent state (a list's size() property gets out of sync with the number of elements it actually provides). Keeping a consistent state in the aggregate root means forbidding any other class in the system to act directly on any internal object of the aggregate if that action may leave the aggregate in an inconsistent state. In this light, value types are actually pretty good things to return by an aggregate root, since they are immutable and you just don't care how far they get passed on into in your application, as no side-effects by its usage will ensue. jorge On Thu, May 7, 2015 at 2:14 AM, Marco Paul [email protected] [domaindrivendesign] <[email protected]> wrote: > > > When trying to keep our aggregates internal structure encapsulated from > clients (app services for example) does this imply not exposing properties > holding value types and all behavior methods and domain events lean with > only primitive types? > > Sent from my iPhone > >