Picon

Are web applications complex enough to domain-driven design?



After much reading and some attempts to implement DDD, I think I understand what people mean when they say the concept was developed for complex domains.

I usually develop web applications for small and medium businesses, usually the interactions are just CRUD application and tables in HTML, which goes beyond this are some validations before inserting the data into a database.

I was reading about CQRS on Martin Fowler's website and a phrase caught my attention: "CQRS is suited to complex domains, the kind that Also benefit from Domain-Driven Design.".

So my question would be how to analyze the complexity of the software?
When applying DDD worth?
Worth applying DDD in software for small and medium complexity?

Thank you!




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



__,_._,___
Picon

Introducing VBooky.com - Help for popularizing and any support!



Dear All,
  It's been sometime since I have got in touch with many. Here's a few updates on what I have been upto.

For the past 6 months or so, I have been working on starting up a company - Fyno Pvt. Ltd. and bringing up a product in the domain of Spa, Salon and Wellness. Now it's been in operation (beta) for the past 1 month or so.

Online Product - www.vbooky.com 
What it is - It is a online marketplace and platform for Salon, Spa & Wellness Industry, India
What You can do - You book your salon , spa services online like your next hair cut or pedicure or relax with a deeply soothing Swedish Massage .. & many more.

Brief Intro Video 

It is still in Beta even as we try to streamline the operations and few technical issues. Any feedback is most welcome :-) 

I need help and support in below areas. Any help is most welcome :-)

1) Popularize the website - Please register, login & book. Please invite at least 5 friends and make a booking. As of now bookings are only for Bangalore locations. 

2) Like Us on Facebook & invite your friends too

3) Spa and Salon tieups - We are working to get as many salons and spas online soon. If you can provide any more, if not not yet listed & you want them, please send the details .

4) Any good publicity - media, online, blogs & introductions & ideas - most welcome. 


​Sorry, if this mail has reached unintended inbox. My sincere apology. I have tried to remove irrelevant email id from my contact list.​

--
Thanks and Regards,
Ingudam Manoranjan
​​


__._,_.___
Posted by: Ingudam Manoranjan <ingudam <at> gmail.com>



__,_._,___
Picon

Revenj - a DDD friendly framework



Hi all,


we've released a .NET backend framework we've been using for years.

It supports rich models (even has some support for unstructured ones) on top of Postgres (and Oracle) so it allows for seamless DDD while avoiding the JSON DB route.

It's BSD licensed and is available on: https://github.com/ngs-doo/revenj


It contains some distinguishing features (with https://dsl-platform.com/ integration):

 * advanced object-o riented LINQ driver

 * no ORM issues since it utilizes objects in the DB [so it might have OOM issues ;)]

 * integration with modeling language based on DDD for describing the domain

 * automatic SQL migration based on modeling language diff

 * removal of various boilerplate (repositories, DTOs, etc...)

 * works on Mono


If you have questions or comments, please let me know.


Thanks,

Rikard



__._,_.___
Posted by: rikard <at> ngs.hr



__,_._,___
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



__,_._,___

Gmane