> * 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.
Really? So DDD doesn't say you should add BL code to your entities?
> 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).
Well, let's not get ahead of ourselves. AOP is quite 'new' compared to
other techniques, and as I'm not in the Java camp,
it's more or less a new territory for me as it is for most of us here. I see
AOP as a technique to inject code into a class. You
apparently see AOP as a way to do software design. That's fine but I don't
care. The thing is that if someone cooks up a definition,
I don't see why I should follow that definition and use the technique solely in
that context.
> 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.
Let me give you an example.
You have an entity class Customer. You have 2 apps to write. There's
this concept of a gold customer. You have to validate
if a customer is a gold customer. Both apps have different rules for that.
It appears to me that you could use AOP to inject this rule code into
the customer entity. You could also write the rule
into a validator object and add that to the customer and use a strategy
pattern. You can also write it hardcoded into the entity
class and keep two codebases.
Now, it seems to me that AOP can be used for this, right? It's a way to
extend the class with logic without adding the code
to the class. Now, you might say "Noo! that's against the goal of AOP", but why
should I care about that? If I don't use mock
objects, am I then violating some TDD contract as well?
The core question is: why do you limit yourself by not using a
technique (!) for some aspect (pun intended) in your program?
You've to know that I don't care about definitions. So if someone says
"That's not AOP, so you shouldn't call it AOP", fine,
I can understand that, but if I get a nickle for every time someone says ORM
for O/R mapping, I'd be very rich, so let's leave that
out of the discussion, ok? :)
Now, back to my example. Of course you can write a validator, or BL
object and add that to the customer object at runtime,
using a strategy pattern. In fact, llblgen pro uses that pattern for validators
and concurrency filter factories.
But that doesn't mean it has to be done that way. Some people want to
add the code inside the entity classes. For example
through partial classes. That's cool, but it mitigates the fact that if they
want to re-use the entity classes in another app, the
BL logic might be outdated and they have to alter it inside the code, creating
2 codebases. Not that great.
I'm not saying it's ideal, but it IS a way some people will write
software.
If you can simply have a set of entities (generated for example) and
inject the BL code at runtime, what's against that? I
don't see it.
[...]
> 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.
Nice in theory, but it won't work in a lot of cases in practise. THe
core reason for this is that it's very very hard to
create the perfect model. In theory, it's logical to create the perfect model.
In practise the model always has flaws and needs
refactoring. If it's re-used in multiple apps, refactoring gets more and more
expensive.
> 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.
Isn't that definition-voodoo? I mean, 'it's not a domain concept, so it
must be bad'. How can a BL rule not be a domain
concept? You just use AOP to inject it in the class.
> 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.
How can I miss some power if I utilize the power of the concept to make
something work which didn't work before?
> 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.
I'm not in school anymore, Greg, so I won't do assignments.
It's also not about 'existing constructs which offer a less releavling
solution'. It's about how people tend to write
software. As an O/R mapper vendor I know how many different ways there
apparently are how people want to work with entities, trust
me on that. Telling everyone that there's just 1 way to do it is stupid as it
also depends on the context of the project, the skills
of the developer and frankly, most of these 'methodologies' have great things
but also sucky things, so a developer is IMHO better
of picking the best things of various methods and work out a good method for
him/herself. I hopefully don't have to come up with an
example how for example TDD zealots try to force you every little aspect of
their methodology on you, even if you just like 50% of
it.
For example a math library is better written in a procedural language.
Yet OO languages also have a math library. Not ideal,
but hey, it's OO so let's write the methods in a big static class. For some OO
fetisjists this is incredibly bad. For others it's
simply using the tools at hand, do their thing and move on. I'm not sure who's
better of at the end of the day.
> 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?
Well, perhaps I'm not as closed minded as some people on this list, eh?
;)
What *I* think about DDD and how people should write software doesn't
make it *THE* way to write software. It also doesn't
imply DDD or other methods suck so much you should avoid them. I just disagree
with some root concepts. I also know others disagree
with me and think the opposite. Perfectly fine by me. Because others use DDD, I
got this idea of using AOP for bl in those contexts.
There are other techniques, I use these as well, though that doesn't make using
AOP for it 'wrong'. There's no such thing as 'wrong'
in software engineering (no not even in the context of stored procedures ;)),
some things have just more cons than pros in a given
context, so it might be not the wisest choice, that's all.
As we're all at the start of an era where software is more and more
generated, where BL rules are more and more applied to
objects at runtime through workflow systems and BL engines, it might be AOP has
a place in that spectrum because it has the
techniques on board to make that happen.
Closing the eyes for that just because it's not compliant with the
definition of AOP is IMHO erm... limiting yourself. :)
FB
ps: did you like the article, book?
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
