Posts Tagged patterns

DomainDrivenDesign: Domain Services or Method on an Entity?

There has been too much discussion on the DDD list regarding where to put the business logic control, whether in a service or entity. Being more specifically, in order to ship an order, the followthings should happen:

  1. Validate that the order can be shipped
  2. Update quantity
  3. Set the status to shipped
  4. Save the order
  5. Send an email to the customer that the order has been shipped

So, nickgieschen suggested the following C# implementations:

1. Everything in the domain:

 1:class Order
 3:    IOrderShippedNotificationPolicy _notificationPolicy
 4:    IOrderRepository _orderRepository
 6:    void Ship()
 7:    {
 8:        if (!CheckIfOkayToShip()) {
 9:            throw new InvalidObjectException();
10:        }
11:        UpdateQuantity();
12:        _orderRepository.Add(this);
13:        _notificationPolicy.Notify(this);
14:    }
17:class OrderShippedNotifyByEmailPolicy : INotificationPolicy
19:    // The object that gets injected is implemented
20:    // in the infrastructure layer
21:    IEmailGateway _emailGateway
23:    void Send(Order this)
24:    {
25:        // Create email here
26:        _emailGateway.Send(email);
27:    }

2. Or have an application service coordinate:

   1:class OrderService
   3:    // _orderRepository and _orderShippedNotificationPolicy 
   4:    //  are injected dependencies
   6:    void ShipOrder(Order order)
   7:    {
   8:        order.Ship(); // in this case it only validates and updates quantity
   9:        _orderRepository.Save(order);
  10:        _orderShippedNotificationPolicy.Notify(order);
  11:    }

There’s been a lot of replies also. I highlighted the interesting ones:

“The advantage of the latter scenario is that you’re calling _orderRepository. Save in the application layer, which I prefer since it’s easier to see the transactional control. The problem with the latter scenario is that it seems it’s putting things in the application layer which don’t need to be there. The action to Ship() seems to me an atomic, domain centered action and should therefore sit in the domain. I consider the application layer to be like a thin domain facade as defined by Fowler. That is, it is only there to direct/coordinate domain activities. Like I said, Ship() seems like it should be considered one activity, and therefore coordination from a service layer shouldn’t be necessary.”

“The way I look at it – what needs to go into Ship() is the stuff that _must_ happen before shipping can happen. And shipping can happen without the notification part. You only have a rule that says “send a notification to the customer upon shipping the order”. You don’t have a rule that says “make sure the customer gets the notification or there are no shipments”.

“So, perhaps as a rough, preliminary rule we can say anything which affects the state of the domain should go be placed in the domain. (Of course, the application layer can affect the state of the domain, but only by using domain items to do so maybe think of it as the Law of Demeter among layers.) The email doesn’t have any meaning within the domain – it’s simply a reflection of the domain.

“Notificitation of an order and the order itself is two separate concepts.”

“This could as easily be implemented using AOP.”

I think DDD advocates are a little bit extremists with some concep
ts, like repository. I wouldn’t have designed it on the domain layer, because I want transactional control on the application service layer. I think the domain has to deal with its particularities, not with sending email or adding things to a repository, even being decoupled of theirs implementations (the domain has a reference only to interfaces). So I prefer the latter approach. And you? What are yout thoughts about this design? How would u have designed it? Everything on the domain or have an application service coordinating the activities?

Tags: , , , ,

Why not design patterns?

Some months ago, Cedric has reported people criticizing the use of design patterns on software projects, with some arguments like:

  • “it’s a sign that your language is fundamentally broken”
  • “focus on simpler solutions before going straight to a complex recipe of design patterns”

and other funny things also. Moreover, some said design patterns was inspired in Cristopher Alexander’s Pattern Language book, although design patterns leverage complexity to the programming languages, totally opposed to the Alexander’s book simplicity proposal. As Cedric said, people do criticize, but not provide better solutions. It’s inside our personality: we often try to find defects in all the ways people realize things, but we don’t like to search for better ways to realize the same things. In my opinion, design patterns are:

  • Patterns for developing object-oriented reusable software;
  • Leverage a solution to a general design problem in a particular context;
  • Promotes design reuse;
  • Promotes a common vocabulary on the software development team;
  • Facilitate software modifications, documentation;
  • Promotes manutenable, understandable, legible code, abstracting aspects of a domain problem;

and some other benefits…

So, what do people want? Every time, every software project implementing the same feature in a different way? Of course we’re not saying here to insulate a lot of patterns in a sofware project, but, come on, why not establish a common vocabulary of software instead of doing things all diferent every time? Why reinventing the wheel?

Tags: , ,