Posts Tagged ooad

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: , , , ,

Generating LGPL notices with Python support

When we started developing JFileContentManager, we didn’t even think to release it as an open-source project. So, when we finished the project, I particularly thought about this idea, because I was very interested in participating on an community involving project. So, we decided to release it under the LGPL licence, because we wanted the project audience to be wider as possible. But, before turning it public, we needed to add the LGPL license term to every Java file of the project.
Opening and editing each Java class, one by one, would be a tedious task, taking a lot of time and adding up to the fact I’m very interested on learning dynamic languages (like Python, Ruby), I developed a Python script to automate this task for us. Our Python code is intended to open each Java file, adding the license term on the start of the file as a Java comment and writing it to the disk. The script is as follows:

 1:# Python script to add the LGPL notices to each java file of the FileContentManager project.
 2:import os, glob, sys
 3:License = """\
 5:*FileContentManager is a Java based file manager desktop application, 
 6:*it can show, edit and manipulate the content of the files archived inside a zip.
 8:*Copyright (C) 2008 
10:*Created by Camila Sanchez [], Rafael Naufal [] 
11:and Rodrigo [[email protected]]
13:*FileContentManager is free software; you can redistribute it and/or
14:*modify it under the terms of the GNU Lesser General Public
15:*License as published by the Free Software Foundation; either
16:*version 2.1 of the License, or (at your option) any later version.
18:*This library is distributed in the hope that it will be useful,
19:*but WITHOUT ANY WARRANTY; without even the implied warranty of
21:*Lesser General Public License for more details.
23:*You should have received a copy of the GNU Lesser General Public
24:*License along with FileContentManager; if not, write to the Free Software
25:*Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA """
27:size = len(sys.argv)
28:if size == 1 or size > 2:
29:    print "Usage: $1"
30:    sys.exit(1)
31:inputPath = sys.argv[1]
32:if not os.path.exists(inputPath):
33:    print inputPath, "does not exist on disk"
34:    sys.exit(1)
35:if not os.path.isdir(inputPath):
36:    print inputPath, "isn't a dir"
37:    sys.exit(1)   
38:for path, dirs, files in os.walk(inputPath):
39:    fileWithLicense = ''
40:    for filepath in [ os.path.join(path, f)
41:            for f in files if f.endswith(".java")]:
42:        content = file(filepath).read()
43:        f = file(filepath, "w")
44:        print >>f, License + "\n" + content
45:        f.close()

License is a Python multiline string, denoted by the triple-quotes. The main action begins with the os.walk() expression that walks every file in the directory, entered by the user as a comannd line argument, like this:

python ${path}

where ${path} defines user project root directory. The list comprehension syntax produces the full path of each of the Java files. When the match is found, the file is opened and its content is assigned to the variable content. So, the License string is added to the start of the file and the file is then written to the disk. The print statements use a redirection syntax, for example: print >>f, License + "\n" + content. The ‘>>f’ sends the results to f rather than the console. So, this Python script helped our team to release the project early and at the same time automated the task of adding the LGPL notices. I think Python is very useful for these kind of tasks. And you?

Tags: , , , ,

Annoucing JFileContentManager 1.2!

A new version of JFileContentManager has been released! Below are the changes release:

  • The tree UI component was corrected to reflect the zip hierarchy content;
  • Added support to show the contents of:
    • Java files
    • Properties files
    • Shell script files
    • XHTML / HTML files
    • XML files
  • The About Dialog has been integrated with JDIC;

Check this out!

Tags: , , ,

JFileContentManager has been released!

JFileContentManager is a Java based file manager desktop application, it can show, edit and manipulate the content of the files archived inside a zip.
Showing a simple and friendly GUI, the user can see the content archived inside a zip file in a tree view way, select one file per time and see their content (either text or image). It’s also possible to reopen the last opened zip files through the history option on the file menu.

Below are the current features:

  • See the zip files’ list in a tree view way;
  • Select one by one of the files and see their content (either text or image);
  • Open the last four opened zip files through the history option on the file menu and
  • Download the bundled executable Jar.

and future goals:

  • Support other file formats, like .tar, .tgz, .tar.gz, .gzip, .rar, .7z.
  • Edit the content of a text file;
  • Save the edition etiher inside the opened zip or at another location on the disk;
  • Select one or more files and zip them together;
  • Edit the image’s file content with the help of a picture toolbar and
  • Bundle the project in Java Web Start.

The project is released under the LGPL license. Misfit, rnaufal and roddy will be very proud and happy if you take a look at this project, running the application, downloading the source code on SVN and commenting about it. Thanks and enjoy!

Tags: , , ,

Single Responsability Principle

Look at these Java code snippet:

   1:import java.util.Date;
   3:class Movie
   5:    private Date exhibitionDate;
   6:    private Director director;
   7:    private Persister persister = new Persister();
   9:    public boolean isDirectedBy(String director)
  10:    {
  11:        // some code here;
  12:    }
  14:    public void changeDateWithDirectorApproval(Date newDate)
  15:    {
  16:        // some code here;
  17:    }
  19:    public void save()
  20:    {
  22:    }

At the save() method, persister takes care of the responsability to update the current movie, saving it at the persistent environment (a file, a DBMS, any data source, etc..) . Some may argue this class has two responsabilities: the Movie is responsible for its own behaviour AND its persistence. ButUncleBob has an interesting opinion about the Single Responsability Principle (SRP). It says Movie actually is not implementing persistence, the persister is a collaborator of the class. The persister is hidden from the client of the class, that is, is not part of the public interface. So, the lose coupling and the encapsulation is preserved. If the persister changes, the clients won’t be affected. It concludes SRP is about implementation, not interface. But imagine if you wanna find a movie, you can’t do movie.find() 🙂 . So, you have to deal with another collaborator who knows how to find a movie. Couldn’t be the Persister? No, because this one is hidden from the clients and if you become it public, you would fail with the information hiding principle. In this case, I think it’s better a Finder object. And you?