Hello jff, 

Well thanks for such great feedback let's see if I can answer your questions!

{quote}
Then you say that "ADM is a model which has the objects and the relations but lacks the business logic".
{quote}

Attention that when I say __lacks the business logic__ doesn't mean that there is no logic at all. It means that the objects that model the problem don't have the business logic in them, the logic is somewhere else like in services.

{quote}
My first question is very simple: if the model lacks the business logic, then it doesn't have anything related with the problem itself (I am just using your previous definition). But aren't the relations and the objects related with the problem? I think that your article leaves this concepts very unclear.
{quote}

Yes, the relations and objects are not only related to the problem but part of the model itself! Maybe I just have written the following instead, the logic that should be inside the domain objects it's somewhere else.\\
But I think the best way is to give you an example!

Imagine that you have a system that manages a library. I think we both agree that two domain objects may be Book and LibraryUser. Now imagine two simple rules:

1. A __Book__ can only be reserved by one __LibraryUser__ each time
1. A __LibraryUser__ can have at any given moment a maximum of ~~three~~ reserved __Books__

On an Anemic Model, where the domain objects have no logic you could have something like the following:

{code}

public class ServiceToReserveBook extends Service {
 
   public void run(Integer libraryUserId, Integer bookId) {
      LibraryUserId user = readUserById(libraryUserId);
      Book book = readBookById(bookId);

      if(book.isReserved()) {
        throw new ServiceException("Book is already reserved by a user");
      }
      if(user.getRevervedBooks().size()>=3) {
        throw new ServiceException("Cannot reserve more than 3 books");
      }

      user.getReservedBook.add(book);
      book.setReserved(true);
   }
}

{code}

Now as you can see the objects __Book__ and __LibraryUser__ do exist! They even have a relation from 1 to many, since the getReservedBook method returns a list of books. But the logic is not inside the domain objects, but on the service.

In the case of the DDD you would have the following:

{code}

public class LibraryUser extends DomainObject {

   // more code here
   public void addReservedBook(Book book) {
     if (getReservedBooks().size()>2 || book.isReserved()) {
      throw new DomainException("error"); 
     }
     getReservedBooks().add(book);
   }
}

public class ServiceToReserveBook extends Service {
 
   public void run(Integer libraryUserId, Integer bookId) {
      LibraryUserId user = readUserById(libraryUserId);
      Book book = readBookById(bookId);
      try {
          user.addReservedBook(book);
      }catch(DomainException e) {
        // code here 
      } 
  }

}

{code}

Now in this case the logic is self contained in the domain objects and the services only need operate the domain objects. This is good, because you stop replicating code on your services. If your business logic changes - for example, users could start reserving 5 books instead of 3 - you only needed to change code on the domain object and not on services!


{quote}
Also, you say that "So when you need, for example, to change some sort of behaviour you just need to change the code inside the object and it's most of the time self contained.". My question is to what extent can you claim that it is most of the time self contained. I would say it is very common to have the behaviour of certain objects dependent on other different objects (and by very common, I really mean the general case).
{quote}

In such context when I mentioned self contained I wanted to say that even after code modifications the object will preserve its interface and behaviour. If this happens, other objects using the modified object won't notice modifications. I see such kind of modification as a self contained one. 

{quote}
As a final remark, let me just say that I wasn't able to completely understand the article. I think the problems were some undefined concepts that I don't know and I'm also confused about the context of DDD -- when can I use it?
{quote}

I'm thinking in starting to write more about DDD and design in general so you might catch up all the missing concepts. But when is DDD used? Well mostly when you have big complex domains because DDD is scalable.


{quote}
  what do you mean by finding a model for your problem?
{quote}

With "finding a model for my problem" I mean finding a good abstraction of the problem and a way to map it in objects.

The main idea is to identify the entities involved on a certain problem (remember Book and LibraryUser on the previous example?), along with the functionalities (reserverBooks). Then create objects that represent those entities and methods on each object that represents the functionalities. 

You may ask if there's a constructive way of finding such models, well I really don't know. I've learned to do it by feeling. \\
When you have a "draft version" you start asking questions regarding functionalities and see how the model behaves, most of the time you'll need to change it a few times until you reach a fixed point.