|
List Info Thread: Re: The effects of ORM in architecture and domain driven design
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
Re: The effects of ORM in architecture and domain driven design |
|
List Info Thread: Re: The effects of ORM in architecture and domain driven design
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
> The thing is, for a small project, it is almost
inevitable for a developer
> to quickly create a db schema, generate sql statements
from the db design
> tool, and create the db, which if followed by reverse
engineering the db
> with orm tools, and bind it to UI. It is the kind of
thing that I've done
> maybe a hundred times or more.
Not only in small projects. Often a team contains
one or more DB
architects who are in charge of designing and maintaining
the db schemas.
> The thing is, when I start with use cases, and a domain
model that does not
> include any concerns for persistence, the results are
different. The uml
> diagram I'm looking at uses inheritence, design
patterns etc, and if you do
> not think about persistence, the look of the code that
uses this model is
> quite clean. It is more maintainable too.
true, from a code perspective.
Though, one thing has to be realized: if you design
a class hierarchy
like Person <- Customer, Person <- Employee etc.,
these types didn't fall out
of the sky: they're physical definitions of abstract entity
types, projected
onto program code.
This means that it doesn't matter if you write a
person and customer
class or that you create a person and customer table: both
are projections of
the same (!) abstract entity. The thing is: an abstract
entity is a definition
of something which is recognized in reality. How you create
your code to deal
with this definition is up to you, however it's wrong to
ignore the fact that
the entity is simply something that is recognized in
reality, so modelling an
entity model is really just modelling what's already there:
reality contains
these entities already.
If a class diagram is created which contains
different types than the
ones recognized in reality, it simply means a conversion has
to take place.
Too many times developers assume that this conversion takes
place in an O/R
mapper layer, but that's a mistake: the conversion has to
take place inside
the code: the conversions I'm talking about are actually
projections: from one
domain to the other. If the conversion doesn't take place,
you can't talk
about 'customer' in the context of the program and if the
conversion isn't
recognized as something required, one also can't talk about
'customer' in the
context of reality. And especially that second part is where
things go
horribly wrong in a lot of application which consume
databases.
> Now this is a clash between two different approaches,
where domain info is
> modelled first in db or in a domain model. The question
is, what is the best
> way to merge these approaches? I am really happy about
using benefits of OO
> in the domain model, but at the end I find myself
writing a "manager" layer
> which connects domain classes to orm generated
classes.
As long as your application logic deals with entity
types which are
simply a physical representation of the abstract definition,
you can make
decisions based on these entities with rules as recognized
in reality, e.g.
based on interviews with the client, research of the
organization the
application is for etc.
The advantage of having entity types which represent
elements
recognized in reality is that your code mimics that of what
should be done in
reality / is done in reality as well. I.o.w. you can reason
about what the
logic should be done by simply looking at reality and how
processes work,
should work, how information streams run, what information
is available etc.
Nowadays this is called 'domain oriented', in
earlier days there were
different terms, but they all come done to the simple fact
that one should
recognize what reality contains about the subject at hand
and use that
information as the base of the software to build.
Never ever fall into the trap that the class model
is the
representation of a) reality and b) what should be done to
make the software
behave in reality as required.
> I am not sure if ORM should be responsible for more
than eliminating the gap
> between relational paradigm and OO paradigm, and you
see all these resources
> referring to ORM classes as domain classes. Check out
any OO design resource
> or course, and you'll see that the modelling of a
domain is rarely performed
> in DB world, where schemas and allowed db types are
your building tools.
> Eclipse Modelling Framework seems to have a binding to
Hibernate for
> example, which is a clear indication of seperating
domain model from ORM
> classes, and I think I am in favor of this approach,
for it allows me to do
> the design based on OO approach, and it also gives the
benefit of being able
> to isolate myself from sql.
Though, it's nothing more than dealing with the
overhead of text-based
code which is a projection of the functionality required: if
the paradigm of
the code changes, if the language changes (e.g. from C# to
haskell), the real
program, the solutions to the problems recognized, the
functionality required,
the entities recognized in reality which are the ones to
deal with aren't
changing one bit.
Thinking in C# statements too often makes people
think that what
they're typing in is the solution, is the functionality, are
the
datastructures required, but they're projections of the
solution,
functionality and datastructures required. Because they're
projections, your
main focus first should be on the source of these
projections, which is what
we're today call the domain model, entity models etc.
And these have little to do with code, class models
and the like.
> On the other hand, ORM based approach simply works! I
think I'm more
> inclined to accept ORM (generated) classes as domain
classes when I'm under
> time pressure and the app is small, and writing down
the connecting layer
> between domain and orm layers when I have more time and
the project is
> larger.
> I'd love to hear what you think about this. How do you
draw the line? Which
> approach is common in your shop?
I wrote a couple of articles about this subject, one
is in Jimmy's
book: 'The datamodel is the domain model' (I always love the
reactions of
code-junkies when they see the title ;)) available here: