I want to design an online book reader. The first step is describing all the use cases which I have listed below:

  1. I should be able to search a book by title.
  2. I should be able to borrow a book.
  3. I should be able to bookmark a borrowed book.
  4. The system should allow one user per book at a time.
  5. The system should allow to add a new book.
  6. The system should allow to delete an existing book.

That said, I know now I need some Service Objects which would operate on Entities / Value Objects to get the thing done. I am deferring the database design / decision for now as its not considered a good practice. For the similar reasons Delivery mechanisms too is deferred.

After some reading I came to the conclusion that I would need the following:

Services (Algorithms without any states, depends on entities / values)

  1. SearchBook (Takes a title and gives the result back)
  2. BorrowService (Checks if a book can be borrowed)
  3. Member service (Enroll/Unroll members in a library)

Entities (real world mutable objects with unique ID)

  1. Library
  2. Book (ISBN number as a UID)
  3. User (Email as UID, it can be author or reader)

Associations

An author can have many books under his name, a user can only borrow one book at a time. A library can hold many books at a time, it can have many members too.

Notes

  1. For simplicity there will be only single library / store.
  2. No two users can read the same book at a time.

Questions

  1. I am not able to find any value object till now or I am not able to recognize / find it?
  2. I have followed Clean Architecture for some time and helped to build a toy project before. What is the difference between this and DDD?
  3. Am I on the right track?
up vote 4 down vote accepted

Did you consider the Book "Implementing Domain Driven Design" by "Vaugh Vernon"? It gives a view on the concepts behind DDD from an implementation perspective with lots of really good real-live examples.

Regarding your explicit questions:

Clean Architecture, as stated by Maciej Chałapuk, is orthogonal to DDD. It is a very sound and solid concept to structure your system and gives room for domain modelling concepts like DDD.

I would not put too much thought into the explicit structure of this bounded context. Try to write a very broad acceptance test of a basic use case against the outer system boundary. Try to implement it with the fewest possible interactors while keeping a reasonable separation between the created components. Write Unit Tests if applicable.

I prefer this outside-in approach ("Growing Object Oriented Software, guided by Tests" is a good reference here), since it drives a domain model that is less gold plated and more fitting to the actual use cases.

I am not able to find any value object till now or I am not able to recognize / find it?

Value objects may be difficult to find in some domains, although in your case I would probably make ISBN a value object since it has formally defined structure and there is some business logic connected with it. Sometimes it is a design decision whether to represent something as a value object or an entity or just a field of an entity.

I have followed Clean Architecture for some time and helped to build a toy project before. What is the difference between this and DDD?

These are two completely different things.

  1. Clean Architecture is an Architectural Pattern which defines the structure of a whole program.
  2. DDD is a method for modelling Domain Logic and separating it from the rest of the program.

They are orthogonal to each other (both may be applied in the same program).

Am I on the right track?

Yes, you are on the right track with modelling. The best source of knowledge on DDD is the book by Eric Evans (author of the method).

Make sure that methods of entities and value objects contain only domain logic (state changes and constraints). All platform-specific code should be elsewhere (presentation, persistence, logging, threading, etc). Entities should have domain methods that are named after business operations. These methods should be called from services (only one call/entity/operation in most cases).

  • Nice explanation, but you got me confused in the last sentence. If I keep all the domain logic into Entities then Service is useless which is a contradiction to Clean Architecture. – vivek Nov 4 '15 at 16:17
  • Sorry. It is a bit confusing. I'll supplement the answer. – Maciej Chałapuk Nov 4 '15 at 19:37
  • Usually I think its better to create a service for each Bussiness Logic and keep the Entity clean by giving it the responsibility of validation rules and serialization. wdyt? – vivek Nov 18 '15 at 4:46
  • Also, as per one of my friend's suggestion I have ordered Vernon. – vivek Nov 18 '15 at 4:47
  • When using DDD, it is essential to contain business logic inside entities. The whole concept is built around this. And it's actually the proper object-oriented design. In OO program you should have objects (bunch of operations) instead of structures (bunch of data). We forgot how to program with all the frameworks that promote bean-like thinking. In DDD there should be no objects with getter/setter pairs. – Maciej Chałapuk Nov 18 '15 at 8:49

SearchBook (Takes a title and gives the result back)

Are you sure you need a service for this? It looks like this is a responsibility of a repository, which was given a Specification, containing book title.

BorrowService (Checks if a book can be borrowed)

Are you sure this is not just inStock property of a Book object? Or, if you have some stock quantity calculations, there should be an object, responsible for this.

Member service (Enroll/Unroll members in a library)

What will this service do? Create/delete users is a repository's responsibility.

Book (ISBN number as a UID)

I am not sure this is a good choice of primary key. A book can have two ISBNs or even more. I am not sure you will be able to find a good natural key for books.

User (Email as UID, it can be author or reader)

So, the user will be unable to link secondary email to his account, right? Also, if you choose email as a primary key, linking to the user in other tables will make your indexes grow. Again, I am unsure if you can find a suitable natural key here.

I am not able to find any value object till now or I am not able to recognize / find it? I haven't find any so far also ;)

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.