Client and server in the same repo
As a media type developer, we typically are mildly bemused by some questions of whether the “front end” and the “backend” should exist in the same code repository. In truth, the entire distinction between front end and backend is a bit curious in and of itself, since developers tend to share code styles, patterns and anti-patterns as well as norms and values about what counts as “good” or “performant” or “relevant” or “clever” code.
Generally, it’s just a bunch of nodes talking to each other. Computers do not know they are “front ends” or “backends”, this must be stated in the request-response volley of messages. One says
GET the other has some
Accept headers, and on so, but in truth at any time a server can become a client, depending on the goal that we has humans have set before us, whether it is to decentralize an economy or simply serve up a web page with a picture of a kitten on it.
Developers, however, are fickle and sometimes flighty: they want these patterns and these conventions, etc. They don’t want “js” or “css” as names for folders, (maybe) unless they’re preprocessors, etc., for these terms are meaningless and not semantic. But in general it is frowned upon practice. At the same time, many developers prefer to break things down, as it were. Everyone loves to be the one who “decomposed the Thing”. It’s tough. The Thing is always a beast or a dragon or whatever. But this doesn’t mean that we should decompose haphazardly: there’s no reason that decomposing a business problem or a scientific problem requires that we have the “client” or “front end” code exist in an entirely separate codebase. We just need to make sure through namespacing that everything is made clear at the moments when we need to run the right program (likely through CLI).
With that, and keeping in like with the Lakoffian “conduit metaphor” strategy as we use these documents to plan projects, I have updated the hypermedia-orientation diagram that I have fused with domain-driven design:
Bottom half of the building… Think of “domains” as the “first floor”. What that means to you is up to you. In my “lab” metaphor, I think of the “domain” as an area within a virtual building in which certain kinds of questions and developments are undertaken. In the “chronological” or “bullet” metaphor, the “domain” is where everything “starts” (day 0).
Trees and branching structures are nice (sometimes), but a-temporally? I dunno. Trees have their own vibe; but “waterfall” is a known project planning anti-pattern in software development. Ask questions, theorize, but probably do not interpret this as suggesting “do waterfall” (do not draw any temporal settings from this diagram, others may suggest as much and it may actually work out, given other assumptions about organizational complexity).
Chronological/Train station map
Looks cool. Reminds me of a train station (or the train itself? I must be into some pretty futuristic trains stations…), but also: it suggests that we should take up domain-first development. Well, what would that look like? This:
Tables will never not be cool.
Traditional concept map
Old Faithful (the “campus”, “colleges” or “holacratic” formation). You could think of each top-level node as a topic or focus delegated to a whole (micro-)team (3–7 people).
Cheers! Enjoy the weekend!
[UPDATE: 11/15/2020] Here are a few PDFs! (not sure if mobile likes direct linking to keybase.io):
Also see the directory: https://keybase.pub/nerdfiles/hypermedia/personal/draft/