@anon20068248 in Fedeproxy Updates, April 2021 - Events - Fedeproxy :
Create a CoderGlue infrastructure in addition to fedeproxy to host another instance of the project. And experiment with them having a federated life together. At the beginning it will be a little difficult because … well because fedeproxy does not exist yet and everything has to be done manually. But it is going to be an ideal ground for experimentation.
This is a nice idea and good way to explore what federated development means. But I was thinking something else, triggered by reading this…
Namely the possible clean breakdown of the “Unified Software Development” domain model (in the way it applies to your project, i.e. tailored to that) into subdomains. Then you have “Federated Proxy” in its own bounded context, i.e. as a supporting subdomain and you have “Federated Development” as your core domain.
Now you can have 2 subprojects, CoderGlue and FedeProxy, where the latter has broader, more general applicability and on that basis might also attract more contributors. Which is good, because you want to focus on your core domain, where you add most of the magic and product USP’s. In any case it is good to know that the proxy part is clearly not your core domain, in a similar way that e.g. User Management isn’t.
Note that there are more supporting subdomain candidates like that (that probably don’t need subprojects, btw), such as aforementioned Community domain. With this you can model all the different stakeholders that circle around a software development project (interacting in Roles, Governance and Processes, as well as Socially… more subdomains in your Context Map breakdown possibly).
When done well, a breakdown like this will lead to modularity and extensibility in your codebase, and a clean MVP from where your Roadmap takes flight.
Note that with my as-yet-unannounced projects Groundwork and Outreach I am doing exactly the same:
- I know that my top-level domain eventually will be very elaborate with many subdomains.
- Based on that I’ve chosen Go-Fed as it allows me to model these subdomains in separate vocabs + codegen.
- My app foundation Groundwork has the requirement for subdomains to be added gradually over time.
- Modularity and extensiblity are key requirements.
- Dynamic pluggability is a nice-to-have initially, becomes requirement in future when there’s a large installed base.
- Polyglot service modules is a nice-to-have, but breaks open the ecosystem for anyone to add value.
- So Groundwork has Service Management as core domain.
- It has Federation, Users, Vocabularies as subdomains among others.
- It has merit to be its own independent subproject, because there’s applicability for any application type to be built on top.
- Outreach is modeled on top of Groundwork as a service module.
- It constitutes a MVP and offers “Grassroots Campaign Management”.
- As such it models Community and Campaigns domains on top of Social (AS/AP) domain.
Both Groundwork and Outreach are interesting for different people. They can be independent projects. For me they are just the start towards a more elaborate federated platform.
Going wild: Visualize the software development lifecycle
This is just me having another interesting showerthought to brainstorm on… @cjs of #software:go-fed tooted the following:
So I’ve been wondering what kind of app to build on top of go-fed for a long while. […]
To which I responded, quoting:
How about a foss and federated https://miro.com / https://mural.co where people collobarate on an unbounded canvas.
Sticky notes, diagram / model types are persisted as OWL-defined vocabs.
One of many applications is a go-fed vocab designer that has process baked in, e.g. starting with an Event Storm, Domain Modeling, ending with codegen, persist in a code forge.
This is another example where thinking in (sub)domains as building blocks might yield a whole bunch of exciting things to emerge, and this can happen in parallel by different project + teams.
- An instance of this tailored to Go-Fed would be a tool to develop for Go-Fed (in an interesting dogfooding manner).
- The application itself has universal applicability in numerous collaborative ideation and modeling scenario’s.
- It would be a great developer tool to offer with Groundwork.
- It would be a unique way to represent the live software development lifecycle in CoderGlue.
Thinking way future here, but how cool would it be to offer a Prezi style overview + navigation over your entire lifecycle and drilldown wherever attention is needed. Instead of static presentation elements you’d see live widgets to interact with both the project itself as well as with the community and those around it?
Note there are at least 3 projects that I know of that approach the UI-side of the equation in this design. They are nodenogg.in, Wireflow, and AutoMerge Pushpin.