Ivory to tower statement: Architecture calls these components and connectors. A component can be something as small as a function or as big as a monolith. A connector specifies the connection and its attributes between two components.
However, connectors can be of any form. They can be based on memory/processor (like local function calls), based on network protocols (like http calls), databases (a system a drops a record another one picking it up), REST (changes to collections) etc. Also some connectors imply higher level concepts such as response and request, message queues etc.
There is literally science about connectors.
IMHO, FFI is a abbreviation used in programming language design to specify the capability to invoke functions not specified by the ABI of the programming language (so the connector CPU/memory/in-process/same-os).
If your perspective/abstraction is that you are a SaaS doing some external integration, this generic rest/http API surely feel like FFI but I would not kidnap a term used for language/runtime design.
Why the derail about Architecture: the words you search are in the science behind Architecture.
Your comment just gave me a brain thing and it’s probably obvious to smart people but here goes:
Connectors are what really matter when it comes to de-risking a project. They’re where you delineate things that are nice to haves. They give you escape hatches (like your data popping out of one component in a format that can be edited by hand, stored, loaded). They let you more trivially replace and upgrade pieces.
Components aren’t all that interesting. They might be a place for optimization but mostly are just implementation detail.
And at any scale I think about in my work, there’s components and connectors. Whether an HTTP API or a function signature.
Is this what the Smalltalk guy meant by it being all about message passing?
> Connectors are what really matter when it comes to de-risking a project.
Yes, they define the architectural style and thus what architectures you can build.
This is getting more and more important because the default architectural style of the vast bulk of our programming languages, call/return, is unsuited for build most of the types of systems we are trying to build.
> Components aren’t all that interesting.
Yes and no. The architecture is defined by the connectors, but in day-to-day programming, your functionality is going to be mostly in the components.
> And at any scale I think about in my work, there’s components and connectors
Yes.
Which is why I created an architecture-oriented programming language that lets you deal with components and connectors
Connectors cover many non functional requirement attributes which like you point out de risk the project.
Components and their behaviors is where the functional requirements are and also many non functional requirements are handled. There is tons of architecture and design space when it comes to e.g. the SOLID patterns (applied to components not objects) and the onion architecture comes into play. So there is tons of interesting stuff to do with components.
About derisking: the core pillar of architecture when it comes to Microservices is finding the right bounded context. This massively de-risk projects as well. It is not so much technical architecture like the mentioned connectors but analysis of the requirements.
Connectors are the primary manifestation of software complexity. This doesn’t mean connectors are bad. They are necessary.
If they are uniform and well understood, then you get to reason about them more easily. That is part of the idea of „the smalltalk guy“ that you refer to. Hint: there is not just one guy.
However, connectors can be of any form. They can be based on memory/processor (like local function calls), based on network protocols (like http calls), databases (a system a drops a record another one picking it up), REST (changes to collections) etc. Also some connectors imply higher level concepts such as response and request, message queues etc.
There is literally science about connectors.
IMHO, FFI is a abbreviation used in programming language design to specify the capability to invoke functions not specified by the ABI of the programming language (so the connector CPU/memory/in-process/same-os). If your perspective/abstraction is that you are a SaaS doing some external integration, this generic rest/http API surely feel like FFI but I would not kidnap a term used for language/runtime design.
Why the derail about Architecture: the words you search are in the science behind Architecture.