Picon

Assigning responsibility for cancelling an Order



During a conversation with our Domain Expert we can across this feature:

"A Customer service agent can cancel an Order by decreasing its quantity. To cancel an Order we decrease its quantity by the specified quantity, change its status to either partially cancelled or fully cancelled and log the CS agent who issued the cancellation."


We are currently split between several solutions (assuming we have the `agentId`, `orderId` and `cancelledQty` from the request): 


**Solution 1:**


    CSAgent agent= (CSAgent) EmployeeRepository.getById(agentId);

    Order order= OrderRepository.getById(orderId);

    agent.cancel(order,cancelledQty);


vs  

**Sol ution 2:**


    CSAgent agent= (CSAgent) EmployeeRepository.getById(agentId);

    Order order= OrderRepository.getById(orderId);

    order.cancel(cancelledQty,agent);


**Solution 1** really captures what the requirements is conveying and reads really well; however, **solution 2** seems more natural when coding the implementation of the cancel() method as I'll mostly update fields in the `Order` class itself which I hope to keep `private` with no public setters.  

The only thing I need from the `CSAgnet` class is a snapshot of its data to be stored with the `Order`.


So how should I determine the best course of action from a DDD perspective?



__._,_.___
Posted by: songoko20000 <at> yahoo.com



__,_._,___
Picon

Thoughts about the Repository pattern and its implementations



Please, take a look at Repository knows about the database schema, a let's discuss:

 



__._,_.___
Posted by: lc <at> leocavalcante.com



__,_._,___
Picon

agrregates vs. aggregates

getting ready for Friday Sept 19th, 2014?

------------------------------------
Posted by: Raoul Duke <raould <at> gmail.com>
------------------------------------

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

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/domaindrivendesign/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/domaindrivendesign/join
    (Yahoo! ID required)

<*> To change settings via email:
    domaindrivendesign-digest <at> yahoogroups.com 
    domaindrivendesign-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    domaindrivendesign-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Picon

Understanding Agrregates



If I have a Customer and a Product and they are related by a Account.

Account than is a Aggregate?


I will have:
Entity\Customer

Entity\Product

Aggregate\Account


Or my Account still an Entity?



__._,_.___
Posted by: lc <at> leocavalcante.com



__,_._,___
Picon

How to assess definitions



Faced with a plethora of notions with overlapping or conflicting definitions, there is a straightforward two-steps routine to separate the wheat from the chaff:
1.The definition must support a clear and unambiguous distinction between the targeted instances.
2. The resulting subsets must directly support a well defined purpose.

As a launch pad, here is a batch of trivial assertions to build upon:

http://caminao.wordpress.com/about/community/a-synopsis-of-trivialities/

Remy.



__._,_.___
Posted by: caminao <at> gmail.com



__,_._,___
Picon

Repository-interfaces: Domain Layer or Application Layer?



Long I have been following the advise of most articles, books and forums to make the repository-interfaces part of the Domain Layer. As many have asked in the past, 'Are repositories part of your Domain Model or not?', the answer usually was 'their interfaces - yes, their implementations- no.' Which, IMHO implied that you should put the repository-interfaces into your Domain Model assembly (aka the Domain Layer).

However, my experience is that those interfaces are never actually used inside your Domain Layer - the first layer that actually uses them is the Application Layer. Isn't it then much more sane to define them in that layer? Perhaps you have always been doing it that way, or is there any evidence is it still best to keep them close(r) to your Domain Model instead?



__._,_.___
Posted by: Wim van Gool <vangool.w <at> gmail.com>



__,_._,___
Picon

Repository-interfaces: Domain Layer or Application Layer?



Long I have been following the advise of most articles, books and forums to make the repository-interfaces part of the Domain Layer. As many have asked in the past, 'Are repositories part of your Domain Model or not?', the answer usually was 'their interfaces - yes, their implementations- no.' Which, IMHO implied that you should put the repository-interfaces into your Domain Model assembly (aka the Domain Layer).

However, my experience is that those interfaces are never actually used inside your Domain Layer - the first layer that actually uses them is the Application Layer. Isn't it then much more sane to define them in that layer? Perhaps you have always been doing it that way, or is there any evidence is it still best to keep them close(r) to your Domain Model instead?


__._,_.___
Posted by: Wim van Gool <vangool.w <at> gmail.com>



__,_._,___
Picon

Re: How does a search functionality fit in DDD with CQRS?



Any ideas anyone?

__._,_.___
Posted by: songoko20000 <at> yahoo.com



__,_._,___
Picon

Learning DDD by doing ..

Hi!

I'm new to the list (and DDD), and have been reading articles a lot
last week or so about it. Very interesting topic!

So the other day I thought I want to start actually applying some of
the ideas I've read about, but first I needed a domain to model. Of
course I could have taken the bald step and tried to model a
subset/bounded context of one of the (legacy products) I'm working on
in my day job, but I soon felt it was too overwhelming to start even
(cannot see forrest because of all the trees being one feeling I had).

Instead I sat down and thought out a "toy problem" to play around
with... It's about a zoo and the yearly maintenance they need to do on
their enclosures (cages, fenced gardens and so on).

When I had done that, I immediately sat down and started hacking, and
hit a brick wall almost instantly. About a million design questions
showed up, and I thought "why don't I ask some experienced people how
they would design a domain around this problem instead"? It should be
simple enough given that the domain/problem is quite small...

So please, if anyone is upto it, please tell me how you would use DDD
on "The Zoo".

http://objarni.wordpress.com/2014/05/27/ddd-toy-problem-the-zoo/

Cheers,

/Olof

------------------------------------
Posted by: Olof Bjarnason <olof.bjarnason <at> gmail.com>
------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/domaindrivendesign/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/domaindrivendesign/join
    (Yahoo! ID required)

<*> To change settings via email:
    domaindrivendesign-digest <at> yahoogroups.com 
    domaindrivendesign-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    domaindrivendesign-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Picon

entities Vs value object



Hi,


I am novice as far as DDD is concerned and I have just started reading Eric Evans book. I might be sounding quiet trivial and repetitive, but I am simply unable to understand difference between entity and Value Object.


If this is already discussed, request you to point me to the discussion. Or else I would appreciate if someone can exemplify it with a real world example.


Thanks in advance.


Regards,

Dhaval Shah



__._,_.___


__,_._,___
Picon

Fwd: Facebook Flux, because, quote: "MVC doesn't scale"

actually... funny to read it and see the part that sounds a lot like
bounded context, aggregate root ideas to me :-)

---------- Forwarded message ----------
From: <elided>
Subject: Facebook Flux, because, quote: "MVC doesn't scale"
To: flow-based-programming <at> googlegroups.com

Hi folks,

Have you seen about Facebooks new 'Architecture', called 'Flux'?
(presented at their F8 conference recently)
http://facebook.github.io/react/docs/flux-overview.html

I'm not totally sure I understand everything here, but their main
bottom line seems to be that "MVC doesn't scale" and so they had to
develop Flux instead.

By skimming through the linked page and the embedded video, I at least
get the impression that they solve a big complexity problem by paying
more attention to the data flow...

Would be interesting to hear what you experienced FBP guys think about this! :)

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

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/domaindrivendesign/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/domaindrivendesign/join
    (Yahoo! ID required)

<*> To change settings via email:
    domaindrivendesign-digest <at> yahoogroups.com 
    domaindrivendesign-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    domaindrivendesign-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/


Gmane