What is this design called?

<p>Imagine a design in which internal packages of a Go program don&#39;t know about one another. Each one runs as a goroutine(s), and has channels for input/output. </p> <p>Some central package hooks them up to one another so that their channel connections make sense--e.g. hooks up the output of the microphone package to the input of the audio processing package.</p> <p>The messages sent between goroutines are not rpcs in the sense that after sending over their output, they wait for something back (the package they output to might not even output to them at all).</p> <p>What is this called, where can I read more about it, and is it generally a good idea?</p> <hr/>**评论：**<br/><br/>NewtonIsMyBitch: <pre><p>Sounds similar to the actor pattern, actors receive messages and send more messages but are unaware of the other actors. Actors can manage other actors( become supervisors) and be managed by a supervisor. Erlang issues this pattern by default immsmc.</p> <p>You could achieve that with golang channels and goroutines quite easily.</p> <p>In a larger sense this then becomes micro services when different applications are involved and talking to one another via a common interface.</p></pre>dancannon: <pre><p>I would look into the pub sub design pattern. This could work well with the microservices that gkx mentioned.</p></pre>shazow: <pre><p>If you simplify it away from goroutines/channels, then it just becomes interfaces. Say you have an audio.Writer and an audio.Reader (similar to io.Reader/io.Writer): You could implement all kinds of readers and writers that support this interface, and they don&#39;t need to know about each other. Just like io.ReadWriter, there are all kinds of helpers that can be passed to each other, each writing a bit or reading a bit, without knowing about each other.</p> <p>Go encourages us to write our core functionality synchronously and make concurrency a usage detail. Once you have your interfaces, your application (or your central package) can spin up the necessary goroutines or channels to support whatever processing flow you need.</p> <p>Another property of what you mentioned is type-switching. Say you have a map of functions keyed on the type that they handle: Then when you get an input, you can look up the necessary handler and run it against the input. This is a fairly common pattern for handling commands, for example.</p></pre>__jason: <pre><p>There are some good names already offered for what you are describing, but I&#39;ll also offer the term, &#34;dependency injection,&#34; because of the way you described a central package stitching otherwise oblivious/agnostic components together.</p></pre>gkx: <pre><p>Sounds like microservice architecture.</p></pre>dhdfdh: <pre><p>Back in the day, we used to call it &#34;programming&#34;. Nowadays I guess people have to assign names to things for some reason.</p></pre>postman_: <pre><p>Giving things a distinct name helps battling complexity.</p></pre>dhdfdh: <pre><p>Complex for whom? Kids on reddit? Never had the issue myself but I&#39;m a professional programmer who doesn&#39;t need labels to explain things for me.</p></pre>postman_: <pre><p>So are giving your variables names like thing1, thing2, thing3, etc.?</p></pre>dhdfdh: <pre><p>You&#39;re off topic. We&#39;re not talking about variables or their names.</p></pre>postman_: <pre><p>Except we are. We are talking about all the concepts (or &#34;things&#34; if you like it more) in software development.</p></pre>