Fri Jun 27, 2003 3:01 pm
Hello everyone,
I've been working my way through the DDD book cover to cover and I'm
currently finishing up Part III. The book has been extremely useful
so far and I can't wait for the finished product; the timing could
not be more perfect for me. At the company I work for we're looking
to refactor the architecture of one of our applications within a few
months and I'm trying to do some advanced planning to come up with
our attack plan. I hope you don't mind my asking a few design
questions that have been lurking at the back of my mind while
working through the book and thinking of the more simple parts of
the domain.
Our application is a 1 year old Microsoft .NET web-based helpdesk
application used for tracking customers, reported incidents,
solutions, etc. and contains entities like customers, and incidents
(cases). Incidents are records of issues reported by customers and
the supporting data surrounding them.
For our architecture, I'm looking at using entity objects (I hope I
have my terminology straight), such as an Incident and Customer
objects, to represent data in the app. and then passing these
entities to repositories for retrieval and persistence of data.
I've come up with a few questions, which may be answered in other
parts of the book that I have yet to read, so I apologize if this is
the case.
My first question:
One of the requirements of the app. is to send out notifications
(emails, pager notifications, etc) when events occur in the system
such as the initial save of an incident. Would these notifications
most appropriately be handled in a Facade object that further
interfaces with the IncidentRepository for persistence? I'm feeling
confident that the repository itself should not have any logic other
than that needed to access the database.
And my second question:
Another monstrous item we will need to implement is a security
infrastructure which limits the data that may be accessed by a given
user. For example, if the application is set up so that Joe User
may only view incidents he created it must not be possible for Joe
to view any incidents in the app. that were created by Sally, Bob,
or any other user. This sounds to me like Specification objects may
be in order, but where would I best implement my security checks?
For performance reasons, would it actually be best to limit the data
within the Repository rather than after it has been retrieved? Or
is there another recommended way of filtering? Unfortunately, our
security restrictions/checks will be much more complex than
just "created by."
How are those for loaded questions? :-) Any comments or pointers
are appreciated. I'm just trying to get my head wrapped around the
more complex portions of our domain design.
Thank you,
`Jordan Matthiesen`
Hi, Jordan. I'm glad you are finding DDD useful. It sounds like
you've got a pretty good handle on it.
> Our application is a 1 year old Microsoft .NET web-based helpdesk
> application used for tracking customers, reported incidents,
> solutions, etc. and contains entities like customers, and
incidents
> (cases). Incidents are records of issues reported by customers
and
> the supporting data surrounding them.
Thank you for including a concrete description of your application.
It really is essential to a meaningful discussion of the domain
model.
> For our architecture, I'm looking at using entity objects (I hope
I
> have my terminology straight), such as an Incident and Customer
> objects, to represent data in the app. and then passing these
> entities to repositories for retrieval and persistence of data.
Incident and Customer both sound like entities. I would quibble with
the phrase that the objects "represent data in the app". They
represent incidents and customers in the app, using data to do it.
> My first question:
> One of the requirements of the app. is to send out notifications
> (emails, pager notifications, etc) when events occur in the system
> such as the initial save of an incident. Would these
notifications
> most appropriately be handled in a Facade object that further
> interfaces with the IncidentRepository for persistence? I'm
feeling
> confident that the repository itself should not have any logic
other
> than that needed to access the database.
You are right that the repository should be restricted to object
persistence and retrieval behavior. The security issues you mention
later could fit that, but sending notifications does not.
The composition of the notifications is a classic service your
application layer could provide, delegating to other services in
your infrastructure layer to do the actual sending. That leaves the
question of knowing when to send it.
The first thing I would do is to distinguish between creation of an
Incident and saving it. If you say that a notification is sent when
the incident is first saved, you combine a technical matter
(persistence) with the question of people being notified when
important things happen. One approach would be to make the object
that passes it to the repository (probably an application layer
object that knows what is going on) pass it to the notification
service just before or after -- in the same method. This method then
represents "what does the application do with a new Incident". It
causes a notification to be sent, and it stores it in the repository.
> And my second question:
> Another monstrous item we will need to implement is a security
> infrastructure which limits the data that may be accessed by a
given
> user. For example, if the application is set up so that Joe User
> may only view incidents he created it must not be possible for Joe
> to view any incidents in the app. that were created by Sally, Bob,
> or any other user. This sounds to me like Specification objects
may
> be in order, but where would I best implement my security checks?
> For performance reasons, would it actually be best to limit the
data
> within the Repository rather than after it has been retrieved? Or
> is there another recommended way of filtering? Unfortunately, our
> security restrictions/checks will be much more complex than
> just "created by."
>
First, let me state that I'm not a security expert. Given that, I'll
put in my two-cents. First, the controlling access to objects based
on security rules would fit reasonably within the concept of a
repository, so that could be a good place to encapsulate the access
logic. If performance is the motivation, then you'd have to make
sure that the security restrictions were included in the queries,
and not just logic inside the repository. Of course, sometimes
people want to prevent the objects from being brought into memory
for added security, also.
A specification could certainly describe criteria for access to
data. I haven't seen this particular approach, but it fits
conceptually. It might take some creativity to come up with an
implementation that performed well, especially if you are trying to
prevent inaccessible objects from even being brought into memory.
Another issue is how the system handles denial of access. Do you
need to have the object in order to give the correct response?
> How are those for loaded questions? :-) Any comments or pointers
> are appreciated. I'm just trying to get my head wrapped around
the
> more complex portions of our domain design.
>
> Thank you,
>
> Jordan
Good luck. And please post more questions like these, and let us
hear how your project progresses.
`Eric Evans`
Eric,
Thank you for the response, it helped me to get my
brain wrapped around other parts of the design as
well. I hadn't looked at service layers much, but now
that I've researched it a bit more I think I see how
to tie it in. I'll definitely post some more as I
work on this. Thank you again,
`Jordan Matthiesen`
ADesignCallingForAFacadeSolution is mentioned on: ThreadView
