Leaven - version 2

[Sławek Sobótka]

Hi

I have gathered terabytes of new experience and thoughts about DDD, so it's time to think about next version of the Project.

Leaven is used in couple companies (at least I know about 7) as a kick start project.

Rafał is actually working on some new stuff, but we wanted to ask you about feedback, opinions and wishes.

Plans for version 2:

1. moving to Github
   
2. more advanced modeling examples: we want to focus on modeling techniques, typical problems and patterns (wrong generalization, thins that change model in time, invariants, functional approach, and many others)
   
3. Modeling Whirpool - support for the process
4. More sophisticated BDD plus Specification by Example
5. sample is going to be more and more complicated, so we think about 3 "levels" of application architecture complexity (see attachment). In general I found that techniques and practices extremly usefull when working with my clients and we want to present them in 3 "packages" - techncially 3 Bounded Contexts that are developed in 3 different "styles"

• basic where we want to present layered logic, building blocks, and 3 types of domain logic (stable, closure, decision about closure) - kind of "meta" pattern
• medium, where we introduce subdomains, 
• advanced, where we introduce 4 "layers" of the model (chapter 16 in blue book)

So questions to you:

- what would you add/remove or change priority?

- what do you thing about 3 "levels" of  architecture complexity (attachment)?

[Maciej Hadam]

Hi,
1. It would good to put a fresh air into presentation layer.
Javascript MVC frameworks are amazing (angularjs, knockout, backbone, ember).

(right now o'm looking for a glue to join: JSON with hypermedia API + CQRS

2. Eliminate casting in dispatch method of gate interface. That's easy:
public <R extends Object> R dispatch(ResultTypeAware<R> cq);

3. When i was studying the leaven i haven't found the solution to accomplish the rule "change one aggregate per transaction", this was a pain for me. Today, I'm a follower of a mutated rule "change one aggregate per commandhandler execution, you can change many aggregates per transaction but separate the change over the event"
I thing that's the most difficult part of DDD, the more examples in this area would be included in leaven the more popularity it would have be;)

good luck!!

[Sławomir Sobótka]

Thanks for feedback

> Hi,
> 1. It would good to put a fresh air into presentation layer.
> Javascript MVC frameworks are amazing (angularjs, knockout, backbone,
> ember).
>
> (right now o'm looking for a glue to join: JSON with hypermedia API + CQRS

Heh, because of gui possibility overflow we decided to go the
opposite: cut off presentation and focus on acceptance scenarios that
hit the server api

> 2. Eliminate casting in dispatch method of gate interface. That's easy:
> public <R extends Object> R dispatch(ResultTypeAware<R> cq);

ok

> 3. When i was studying the leaven i haven't found the solution to accomplish
> the rule "change one aggregate per transaction", this was a pain for me.

This rule is useful in context of scalability (and very specific
assumptions about scalability).
Technically its simple: just use events. But modeling problem this way
may be a challenge...

We could think about technical constraint that blocks changing more
than 1 aggregate and forces developer to use event.
But what about use cases when we just need to change few aggregates?

> Today, I'm a follower of a mutated rule "change one aggregate per
> commandhandler execution, you can change many aggregates per transaction but
> separate the change over the event"

So You must have synchronous events and TX "above" all this "process".
What about accidental complexity?

> I thing that's the most difficult part of DDD, the more examples in this
> area would be included in leaven the more popularity it would have be;)

Modeling in this manner may be extremely difficult. Question is: when
is it worth doing so?

> good luck!!

Thanks:)

[Maciej Hadam]

In most cases i use the "mutated rule" for additional things to do, and yes, there is a sync listener.

Going back to presentation layer, this could work as a hook in search engine for a junior devs looking for a solution
about "sparkling label in html" ;)

--
You received this message because you are subscribed to the Google Groups "ddd-cqrs-sample" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ddd-cqrs-samp...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[K.Ciesielski]

Inspired by Greg's talk: http://skillsmatter.com/podcast/design-architecture/ddd-functional-programming
I have been tinkering with functional approach with event sourcing. My project uses Scala + Akka (backend), Twitter Bootstrap + AngularJS (frontend) and MongoDB for storage. It's an experiment in early stage but I thought it might be worth sharing to spark some ideas for Leaven2.
https://github.com/kciesielski/ddd-cqrs-leaven-scala

[Liu Tiger]

I dowloaded your project and study now.

Thanks!

[Liu Tiger]

Thanks Ciesielski!

Your sample is excellent! I'm learning Scalatra and DDD, Can you post some blog or article for project?

Best Regards!

Tiger

在 2013年2月11日星期一UTC+8下午11时45分04秒，K.Ciesielski写道：