Thinking out loud: part of my thinking in how I am approaching #FeatherPub is what I started thinking of as the "boids model" of federated software development.
"But Hrefna, I sure as hell didn't hear about the 'boids model' in my SE classes"
Yes, this is just kind of my own colloquial thinking about it.
For those who are unaware, boids is an artificial life simulator based around the flocking behavior of birds. The idea is that we can simulate general flocking with a few basic rules.
This isn't a "formal software architecture" or "software engineering methodology." This is a rough set of principles.
But basically my thought is: we aren't going to get a single unified standard to rule them all, and there's significant resistance (some right, some I think it is misplaced) to forking.
But we might be able to still develop in a common set of directions, especially around specific aspects (like data privacy guidelines or trust and safety tooling).
Also: if we try to maintain compatibility with those around us, it isn't the "oh yes I'm compatible with ActivityPub therefore I can talk to anyone" that some talk about, but it does mean that everyone is roughly compatible with at least some other services.
I don't consider this ideal in several ways, but I for my own thinking and my own project this may be good enough.
@hrefna I continue to circling back to the ideas of DDD Strategic Design where you craft Bounded Contexts which are the consistency boundaries within which your own fedi use cases are well-defined.
Beyond the boundary all bets are off, and someone can use the same Activity/Object with different meaning and heuristics. If you nonetheless want to interface with them, the DDD pattern to use is an anti-corruption layer where you account for these differences.
@hrefna note that it is important to just focus on "strategic design". If you do a search on DDD you are overwhelmed with the "tactical patterns" parts and tons of confusing stuff on various implementations.
Strategic design is a very comprehensive method, a "way of thinking", that helps get out of the technical impl details at the start of a design. I always say "if you don't do explicit strategic design, you still do it implicitly".
I'd say adjacent. So the Design Patterns come into play when considering the DDD "tactical patterns".
DDD started gaining popularity in OOP realms, and initially the tactical patterns / design patterns got all the vogue. Strategic design was mostly overlooked.
This is also why many people when mentioning DDD to them immediately reject it.. they think back of that time, and passed the OOP/UML/Java stages in their mind.
Searching for DDD also involves distilling lotsa cruft.
Thank you and that gels with my sense about the “schematic” like an actual physical blueprint versus the “material” challenges of implementation. I picked up recent DDD for the schematic.
Note that there's a whole interesting community of folks into #DDD#CQRS and #EventSourcing who moved away from Xitter onto the Fediverse.
I was just followed by @oskardudycz who is among those, maybe having seen this discussion?
What I would be very interested about is to get some expert opinions on how we might scale these architecture patterns and EDA and map it to our #SocialWeb.
A social web of interconnected components & services would be fabulous. #AppFreeComputing
@smallcircles@dahukanna@hrefna I agree that DDD techniques could be helpful here. I'm not an expert in Fedi, so hard to tell me now if it's more a domain or technical problem.
Still, my rough guess is that it'd be worth distilling semantics and behaviours we have and we would like to have. One may represent the state as is, the other intended. It's worth doing both not to get lost.
Having that it'd be easier to break it down into smaller modules, find dependencies and slice them 1/
@smallcircles@dahukanna@hrefna I think that definitely concepts like CQRS (so slicing our application vertically by behaviour), Context Maps, C4 model can help in finding the way.
Event Sourcing and EDA can also be really helpful in terms of integration based on semantics and precisely what has happened.
Tho to give more precise suggestions, I'd need to lear more about the context and concept.
Thank you. ActivityPub seems deceptively simple at first. Yet, it is so flexible that without having some core design principles and clear guidance one is almost certain to implement a non-interoperable dialect.
In theory by defining this core (minimum spec) and a robust extensibility mechanism (guidance) a DDD-like design methodology might be followed, up to doing EDA event/msg design.
And lastly all that might also be conforming to Linked Data, as a bonus.
@smallcircles@hrefna watched the video. I’m an old OMG/UML guy :-) so lots of ideas sound very familiar. GradyB still hates my guts I believe.
Strange terminology, though. One of the key tenets of doing this kind of thing well is to use good terms for everything. Terms like “bounded context” fail the test imho. But the ideas are good.
Nice! Why would you say it fails the test? Btw, I just replied mentioning Concept Design, which is a somewhat different take.
I could see that we get some issues wrt application domains vs. business domains. The current fedi is highly app-oriented and the data models / msg formats reflect that.
In that sketch I made wrt Compliance Profiles the most granular blocks aren't exactly bounded contexts either (though they could be), are sometimes more like (reusable) Concepts.
@smallcircles@hrefna oh, if you do a domain model, and you encounter a duck, it is useful to call it Duck, not PondDwellingDinosaurDescendant. This applies one meta level up as well, when you analyze the domain of design. If the BoundedContext is basically intended to be a localized controlled vocabulary or model, why not call it ContextualDomainModel or LocalizedDomainModel or something that conveys roughly the right idea even without explanation.
Yes, but it is a good point. Not long ago I had this discussion about the fact that we all have these babylonian confusions in our discussions because we have never defined our own Ubiquitous language well enough.
What is an AP extension? What's a vocab? What's an instance? An app? Where do they fit, how do they relate? Or even what protocol layers do we discern?
@smallcircles@hrefna in this context, imho one reason is that many people aren’t aware of how critical good language and well defined concepts are for good systems/software architectures and design. Unfortunately, most of us who know that kind of stuff learned it in the 90s and it somehow has disappeared from the curriculum since.
A focus on app vs business domains is interesting, as it will lead to very different designs.
You can see this in forge federation. Here existing forges (Github, etc.) are analysed and a federation model created. That's an app domain. Forges typically chunk stuff into lists: issues, PR's, wiki pages. In other words a forge is a particular abstraction as helpful tool, an app
The business domain that this app supports is Software development, which is way more process-oriented.
But DDD has progressed a lot since then, and is combined in a whole bunch of architecture patterns and flavours. It's best to hone ones understanding by finding information nuggets that match own dev direction.
@hrefna where I'd like to go is get this separation between thinking about the domain and use cases one wants to bring to the fedi such that it allows non-technical 'domain experts' to come along, and separate that from all the discussion where it gets complicated, which ultimately relate to the impl details of the protocol if it were well-defined and robust.
One vid I found particularly inspirational, more on the impl side, is Domain Modeling made Functional by Scott Wlaschin: https://yewtu.be/watch?v=2JB1_e5wZmU
"Modern" DDD goes into being functional-reactive, and this may map well on Vert.x too.
Architecture patterns often encountered, that go well together are CQRS, ES, hexagonal/clean architecture, actor model.
An architecture may have AP support just as a port + adapter. A challenge is mapping an EDA onto AP, as AP isn't truly event-based.
@hrefna wrt those architecture patterns and how that relates to Strategic design..
The design should inform the best choice of pattern. If you have a "core domain" with a complex bounded context and/or one to evolve a lot then CQRS/ES might be chosen.
A supporting domain for a less important part of your solution may just need a way more simple CRUD design.
And for a generic domain, e.g. user management, you might just choose an out-of-the-box existing library to integrate.
I think wrt Fediverse services & apps what Strategic design brings is a proper thinking about the 'Ubiqitous language' i.e. the naming of all your concepts to conform to the actual domain the experts understand best.
That should ultimately translate to well-defined vocabulary extensions, and good descriptions of the logic that work on these concepts.
If we want to have good interop with your neighboring boids then best collab on bringing as much conformity as possible in this naming.
A thing one might observe wrt ActivityStreams is that it provides a toolbox of 'social primitives', but that the meaning of the names isn't ubiqitous, and people pick objects and activitites for their own purposes incompatible to how the next person uses them.
@smallcircles This has definitely been a core part of one of my challenges in understanding this space.
Because there's a tendency to pick the "closest match" (for understandable reasons, not a criticism of them) rather than define a semantically distinct version.
Yes, AS as a universal basis while not well-defined as such is confusing for everyone. Gives wrong expectations of interop.
Note that DDD strategic design isn't a perfect match to AS/AP-done-well, but imho can inform a good design methodology.
There's also a somewhat different approach of Concept Design, focusing more on reuse (components & services), and both may be combined. See: https://arxiv.org/abs/2304.14975
Thank you for that reference. Yes, but I think sorta kinda, in that "Information Architecture" indicates a much broader field.
Strategic design is "somewhere in there", is just a tool and in itself is very compact and comprehensive. It is the part where you collect stakeholder feedback and shape it into common language. It can be entirely non-technical in a way such that you can keep the stakeholders along for the ride as domains are implemented and solutions evolve.
Similarly, when I see duality characteristics and there isn’t an existing software model that provides architecture blueprint for what I need to “build”, usually fall back to physics of light or flow dynamics as first principles and work up principles, heuristics and rules from there.
I am intrigued by cells in a living organism. How do they self-organize into complex systems and subsystems? They are all autonomous and thrive on a balanced supply and demand of proteins, i.e. msg exchange.
Add comment