* No on the contrary. If you want to do true DDD, and you want to
re-use your entities but in a different context / app, you
will run into the problem of having to alter the BL code inside the
entities. With AOP you can avoid that. That was my point. So
1/ntier development style.
*
Frans,
I would love to see you post that to the DDD mailing as a best practice. I
think you would have better luck selling tickets to a bull fight at a PETA
rally.
I am curious as to how many times you have actually tried this, I have read
about such possibilities in academia (all of which were using languages with
aspect support btw) but I have never seen someone try to actually implement
it ... let alone implement it in a language such as C# which does not have
language based aspect support (yes you could use something like EOS but at
this point we enter into completely obscurity).
The general goal of AOP is not to move the core concern out of an object, it
is to modularize cross cutting concerns. This modularization has huge
immediate gains in the form of reducing coupling and simplyfying the domain
allowing objects to deal with their core concerns (a perfect example is
caching the return value from a service). If you are not actually reusing
your aspects in multiple places you have added a significant level of
complexity to your system with almost nothing to show for it.
Before I would even entertain the idea of using aspects for this purpose I
would first need to see an advantage over the existing constructs, this
advantage would also need to be significant as using AOP in this way is not
only unorthodox it is also extremely expensive when it comes to the learning
curve of the domain (just to be clear here I am saying that using AOP for
business rules that are not cross cutting concerns within DDD is
unorthodox). It is also fairly expensive in some cases on run-time
performance due to the indirection occurring through the use of a run-time
proxy, let alone the problems it can cause with things like serialization
(especially when dealing with inner type members).
When I look at the existing constructs I see existing well known ways of
dealing with these exact issues. Some items that come to mind would be the
strategy pattern, the (composite) specification pattern, inheritance, and
dependency injection. Using a combination fo these items it is in fact quite
easy to abstract business logic away from an object for cases where it may
have multiple definitions.
I propose that everything can in fact be done in a less convoluted way
without using an aspect framework by applying a few very basic concepts. I
also suggest that a solution using only these basic concepts is at it's very
root more maintainable at the present level of the fields AOP knowledge as
it does not includes the concept of aspects.
As a proof that all of these items can feasably be done using these basic OO
concepts I point to how runtime based AOP works (in specific the dynamic
proxy). Since in .NET 90% of the aspect frameworks work through the concept
of a dynamic proxy (in specific they tend to work throguh instance proxies)
I can logically deduce that I could in fact apply my business logic through
inheritance as well.
Feasability aside people generally would not want to apply business rules in
the form of aspects as opposed to something like the strategy or the
specification pattern as the pattern based way of doing this is both more
flexible and is more intention revealing. Strategies/Specifications benefit
from being given their own objects because it helps to abstract the
concept within domain. Eric Evans gives a great example of this in his
explanation of the specification pattern (in particular the discussions
around the cargo example). In this discussion the specification does in fact
become a domain concept (and a part of the ubiquitous language) where as it
would not if applied through AOP.
The concept of domain driven design is about expressiveness before it is
about reuse. A well distilled domain that actually is a good model will by
its definition be able to be reused at another location that shares the
space. If it is not able to be re-used one should be questioning the
original model and looking for ways to make it more expressive, not simply
throwing decorations on it for the new model.
The biggest place that these definitions would hurt a domain is in the
concept of an ubiquitous language. Specifications/Strategies compliment the
ubiquitous language where as aspects (for business logic) would confuse it
as the aspects themselves would not be domain concepts.
Just so that I am clear, I believe in using aspects at the domain layer (I
personally use them heavily). I do not however believe that they should be
used for non-cross cutting concerns as you are gaining little in their use.
If the aspects are providing modularization then I am all for them, if they
are simply 1-1 relations with business logic I think someone completely
missed the real power of both concepts.
My challenge to you is to come up with a hypothetical situation where you
have a non-cross cutting business rule that the existing constructs offer a
less revealing solution for.
Also, from everything I have heard/read you completely disagree with the
very root concept of domain driven design so I am curious where this
opinion/advice comes from. I think the title of your paper in ADDDP "The
Database Model Is the Domain Model" really summarizes your position well.
Given that you completely disagree with the very root concept of domain
driven design, how can you profess strategies for implementing domain driven
design?
Cheers,
Greg Young
On 6/3/06, Frans Bouma <[EMAIL PROTECTED]> wrote:
> > AOP can be used to 'inject' BL code into domain
> classes without
> altering them. This could lead to more code-reuse as you can
> >re-use a set of domain classes for various projects where
> the GUI and
> >the
> BL code changed but not the domain classes. If you had
> >written the BL code inside the domain classes, you would
> otherwise have
> >to
> re-create them for the project with different BL code.
> >
> > FB
>
> Sounds like you subscribe to the NTeir style of development there.
> ...
No on the contrary. If you want to do true DDD, and you want to
re-use your entities but in a different context / app, you
will run into the problem of having to alter the BL code inside the
entities. With AOP you can avoid that. That was my point. So
1/ntier development style.
Sigh.
FB
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
--
If knowledge can create problems, it is not through ignorance that we can
solve them.
Isaac Asimov
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
