normally you have one aggregate per repository. So Repository.addJob(Board board, Job job) seems not a good choice. I don't know your problem domain .. but when we have Board as an aggregate or Root Entity of an Aggregate then Board is responsible for managing its jobs. So it keeps a list of its jobs, where Job is probably another entity. In general an aggregate is a cluster of connected domain objects and acts like a Facade for manipulating its state and the state of its entities and value objects.
By applying these principles you would end with maybe something like this:
Board.addJob(Job job)
BoardRepository.add(Board board)
If you queries are getting too complex and don't fit with your DDD model, then it's completly ok to logically seperate the write and the read model by simply adding an additional QueryService which maps simple dtos to your database.
Hope i could help a bit :)
Repositories are your abstraction to your persistence strategy. So you would have one interface for your repository in your domain layer:
interface BoardRepository {
add(Board board);
update(Board board);
delete(BoardId id);
get(BoardId id);
}
If you would use a SQL Persistence Strategy, then you would implement this interface in e.g. your infrastructure layer like this.
class SqlBoardRepository implements BoardRepository {
...
}
So yes Repositories are responsible for persisting aggregates. You'll have one repository per Aggregate! Not one Repository for every Entity!
Primary Keys and foreign keys are a database related topic and normally you don't care about them in your domain models. Entities in you domain model are identified by business keys (which also can be used as primary key). For example an isbn identifies a book world wide and would be the business key of a Book entity and could also be used as a primary key in the database. Sometimes when using business key is too complex in your persistence model then you could use an additional surrogate key in your entities, which identifies your entity primarly on the persistence layer.
You model your relationships between your domain objects with your business or surrogate keys in the db and a sql repository is responsible for mapping your domain models to database and vice versa.
Maybe you should read a bit about it, then you'll understand better. The blue book from Eric Evans or Implementing Domain Driven Design from Vaughn Vernon is a good start :)
