Re: DDD on DSL Platform

On Thu, 18 Jul 2013 07:49:46 +0200
Tom Eugelink <[email protected]> wrote:

> Interesting and confusing. I'm not sure I agree with the definition
> of aggregate that is being used. Aggregate roots have to do with
> transactional boundaries, and may or may not consist of multiple
> entities and value objects. The DSL-platform however describes them
> as "containers for entities and value objects" and "aggregate root =
> view starting from an entity". Aggregates are not views.
> 

Thanks for feedback, we'll try to clear out any confusion in
terminology we've introduced.
I see that docs say under "SQL modeling will recognize a mapping
between this objects and relational database"
that "aggregate root = view starting from an entity"
While this may be confusion it's actually true in our implementation in
a sense that aggregate root, as a document like structure is a single
view in Postgres/Oracle.
What this means is because we are not suffering from Impedance
mismatch, even if we are running on top of relational database,
a single aggregate (when it's more complicated) spans several tables
and can be queried from that view in a single select statement.

> What is interesting and confusing is that I'm not sure about the
> value of the DSL. I mean, it is readable, yes, but where does the
> logic go? What I'm seeing being generated are anemic models. Also,
> code generation usually results in some kind of worst-of-all-worlds
> solutions, and prevents the flexibility and limits the options that
> using a specific programming language has. Code generation usually
> only works on simple (CRUD) applications, on more complex systems it
> at best can only help by generate scaffolding.
> 

We'll since I've been using this system for a very long time, I surely
disagree on a lot of points, especially flexibility and complexity.
Since Platform takes care of all the plumbing and it doesn't require
manual intervention, it can be used (and we are using it) for very
complicated systems.
Traditionally DDD has a lot of overhead and because of that it is
recommended for only the most complicated systems. What we are trying
to do is take care of that overhead and maintain all volatile parts of
the system from DSL model. Which means that core parts can be done in
a DDD way with generated parts being used as DTOs, persistence and view
models and less important stuff can be done using only generated parts
with few transaction scripts and services on top of it.

> My compliments on the effort, but right now I'm not intrigued.
> 

Well, I hope to change that ;)
I'm certainly interested in parts which people don't like so we can
improve them.

Thanks,
Rikard


------------------------------------