We MUST get clarity on all the different Fediverse-related concepts and their relationships.
What is our own Domain?
In the portal content thread @helge quotes from my toot about having a Glossary. We NEED a glossary.
But we need more than that.
Somewhere in any fedi project and before or in parallel to deep-diving in tech issues, fedi developers are inevitably involved in doing some form of Domain-driven Strategic Design. Whether they do that explicitly or (in most cases) implicitly without being aware they do it.
DDD Strategic Design simply means figuring out which abstractions you are going to code, and what names to give them. You need to learn about the domain to do so. Gain enough expertise to code the right things.
Currently we do NOT know enough about our own domain to create good standards and process.
Ubiquitous language
In DDD terms the word for Glossary is Ubiquitous Language (UL):
Ubiquitous Language is the terminology that all stakeholders agree to use consistently when referring to concepts of a particular domain so that there is a common understanding of the domain.
Or in a picture that looks like this:
(source: infoq: ddd context mapping)
In the UL we should answer “What is an Extension?”, “What is a Vocabulary?”, “Are these proper namings, or should we rename?”, “What is the complete set of terminology we use?”.
Concept map
Having the UL, the Glossary, we should go further and figure out the relationships between the terms. And these might be diagrammed in a Concept Map. This concept map explains concept maps:
(source: askopinion.com)
All kinds of assertions can be listed this way about AS/AP and trigger discussion to improve the domain model. For instance if I’d just brainstormingly gave a kick-off of this exercise, I might type stuff like:
- A Pluggable Protocol can_have Protocol Extensions
- ActivityPub is_a Pluggable Protocol
- A Protocol Extension is_defined_by an Extension Specification
- An Extension Specification defines Message Formats
- An Extension Specification defines Message Exchange Patterns
- An Extension Specification provides a machine-readable Message Context
- etcetera …
(Note: Don’t worry, just example. Consensus on our UL is a collective effort )
(Note: Interestingly the UL when written out forms triples à la Linked Data )
Domain modeling the Fediverse
The usefulness of DDD Strategic Design goes further than use for our own domain. If you are some developer creating an eCommerce app, or a Cooking Recipes app, or a Bike Rental app, then:
- You must model those domains in your code.
- You must find correspondence to other domains you want to interoperate with.
- That correspondence affects your AP extension design (vocabs, behavior to take into account).
So you might immediately do that on a technical level and code LD message formats in your project. Or you might do it with pen and paper on a napkin using DDD and create a good design with much less effort.
Bounded contexts
AP extensions are the techical representation of a Bounded Context in DDD. This is best demonstrated by another diagram:
(source: infoq: ddd context mapping)
In this example the BankingAccount
has different behavior (message exchange pattern) depending on the bounded context. One context might be implemented as a federated Banking app in one project, and the other a federated Expense Tracking app provided by a completely independent group of developers.