Correct approach for different types of concept?

[ErlanBazarov]

Let's say we have two concepts: Book and BookBeingSold. Book have methods like read, rate, and have properties like title and author. BookBeingSold have the same methods and properties but it also have additional methods buy, cancel, changePrice, and property price. The database have two tables books (id, title, author) and books-being-sold (id, book_id, price, is_deleted).

What should code look like for this scenario in DDD way? Should we create two separate modules book and bookBeingSold and two separate repositories? Should we inherit one module from another? Or we should just have one module book and one repository?

[Sairyss]

I think you are mixing up two completely different concepts:

1. A Book that has its set of properties like author and title and can be read
2. Something that has a price and can be sold, no matter what it is, it can be a Book or a Pencil. lets call it a Product.

Each have it's own unrelated business logic. Why you need a BookBeingSold with the same methods as a Book? You can just have 2 separate entities:

a Book:

class Book {
  id: string;
  author: string;
  title: string;

  read() {...}
}

And a Product (you can call it differently):

class Product {
  price: number;
  productType: string; // <- product type is a "book" here
  productId: string; // <- book id

  buy() {...}
  cancel {...}
  changePrice {...}
}

rate method that you mentioned belongs to a Product too IMO and not to a Book (unless your Book has non-generic ways of rating it that are different from other Products).

With this approach you can add more products, not only books.
The key of DDD is analyzing and defining proper bounded contexts for each entity/aggregate/module. Book and Product are two unrelated concepts that shouldn't be mixed.