Like I said before, you are on very good path in terms of gathering feedback. The ‘domain expert’ part was said with a wink because you are getting there one way or another. Words and sentences from these interviews will be transformed into types and code, and by that you’ll have defined your project’s ‘ubiquitous language’. DDD is only there to help ensure a clean translation and a continued correspondence to things your stakeholders understand.
Ultimately in most cases the domain model is that part of the abstraction of the real-world expertise and practice that is relevant for the application. I.e. it is tailored for what you want to offer, containing only those entities and relationships where product functionality will be delivered.
But for fediverse in general, and FedeProxy in particular, you have some additional non-functional requirements, that demand extra care in the domain design. Interoperability requires a model that is broadly understood and accepted, that can be readily reused. Modularity and extensibility are other NFR’s that make this very important. Some entities will directly translate to AP message formats. Note that both AS/AP and ForgeFed - without using DDD terminology - did just that. The domain is directly visible in the vocab data models here. Other entities + relationships may be directly tied to UI widgets to manage them, or be reflected in an API design that allows other projects to provide extensions.
How you split your domain is up to you. The decision to split comes naturally during elaboraration. In an ECommerce domain it makes sense to split between Ordering and Shipping and Billing. They are different processes and even different departments are often involved.
If a project was building e.g. a Continuous Integration product, then a code Commit might trigger the CI Pipeline to be set in motion. CI is the core domain, and Commit may be part of it, but it might just as well be Trigger, or whatever. From the perspective of the CI project a relationship with Code Forges may be designed by means of a supporting subdomain. It is only supportive, because not core to what may trigger the pipeline, and there can be multiple different triggers.
When this project in addition to CI also offered features related to Code Forges domain, then Commit would be defined in both bounded contexts, and may have different properties. Only those that make sense within the subdomain. But there is a relationship and one can be correlated / translated to the other (in your DB they may be persisted as one and the same entity).
Some examples in ForgeFed about the Context Map and bounded contexts. Their core domain is Source Control Management, and not Issue Tracking. They define a Ticket (their ubiquitous language choice, where I am used to ‘Issue’) within the core domain, but not a Comment on an issue, or a Milestone or Release.
ForgeFed defines a new Actor type Repository as an independent entity to interact with (i.e. an agent), but does not include Person actors or Organizations, which are already part of the Social Networking supporting subdomain. In a project based on ForgeFed a Comment will maybe also be mapped to this domain, i.e. by representing it as a as:Note object (whereby assuring that e.g. Pleroma / Mastodon may understand it, if it were sent as a toot).
In FedeProxy you’ll make similar decisions. If you want to highlight the people involved in software development and their interaction, then you’ll build on top of Social as well. In this domain you have e.g. Person and Group actors. Quite bare in their definition. Question is: Is that enough to model a project’s Software Development Community? I’d say No. People have well-defined Roles, and as they change hats they are involved in different activities.
Based on this you may reuse the Community vocabulary that is being discussed elsewhere in this forum. You may give the entities different names / labels. Is Project part of the FedeProxy domain? And does a project have Members? Is the membership the same as the Community membership, or are they different? Is Community an intricate part of the FedeProxy domain? Can membership be divided into Teams? Is there a Development Method in the domain? Are team Roles dependent on the Method?
All these questions can only be answered by gradual analysis and elaboration. You only take what you need, keep it high-level and fill in details and blanks as you go along. Things all start by finding the ubiquitous language, keep lists of terminology and write simple English sentences to describe relationships.
From this you scrap and refine, until you have language that represents a MVP and possibly a Roadmap from there onwards. It will naturally translate into code abstractions, and also provide many handholds as to the architecture that is needed to support it.