Presentation Workshop

Talk idea: What is the roll of utility services in an architecture. Like JSON, HTTP, File, etcetera. They seem to break all of the rules of SOLID principles and get used globally without any concept of ring architecture or imperative shell/functional core. How do they get away with doing that? Programmers use these tools everyday and violate these principles everyday and somehow we don’t seem to care or know why it is like that. We just write a pass for things like that and only tend to apply architecture to our own code. (Maybe the talk about churches and building architecture will be a good talk for this) on another note, knowing the answer to this will probably also give some insight into how to do microservices and regular code ase architecture when it comes to bounded contexts vs the Unix ohilohpspy.

Spin Off Talk idea: Using Istio to make utilities for you microservices that can be sued in the same way. I’d have to write a Sidecar type of utility and provide a tutorial on how to do it.

I wonder if it’s worth reading about DDD and DCI to gain more of an understanding for this.

Talk Idea: Using Elixir in a microservices world. There is a lot about Elixir that isn’t suited for microservices. The BEAM or whatever it’s called doesn’t like to be shut down and booted as a microservices or server less function. But is there a middle ground? Is there ever a time when it makes sense to do that? Could be a talk to explore this.

Presentation Idea

• Some choose to use the Unix-philosophy for architecture.
• Some choose to use bounded Contexts and DDD
• I noticed that when I was working at On-Site that they approached integration architecture primarily from a utility based philosophy. So the main effort was applied in creating a universal Soap interface, a universal HTTP interface, a universal integration timing interface, a universal mapper, differ, etcetera. But within context, it meant that every change made for an individual integration needed to take into account the changes made in other interfaces. Often times the way interfaces had been DRY’ed would obstruct the architecture needed for other contexts. This was because there was too much attention paid to this upfront and it was over optimized prematurely. With an approach like this, your effort is always going to be on defining those contexts and the main pains that will be felt will be
• I wonder if there are any deeper notes from Alan Kay or some original computer science person that has a deeper understanding of the Unix vs Bounded Context philosophy. Maybe something on the better abstraction. Also the Rule of 3 is cited a lot it might be worth talking about that.
• Slide visualization of those approaches. With a Tesla and a Starship. Engines and Propellant would be utility based, the challenge there would be to extract context from that
• How they approached from Unix based microservices and forgot context
• Other approach bounded context first Tesla and Starship first. The challenge being to be mindful of things that are being reused and pull out utilities
• Things that are apparently the same are not instrinsicallt the same
• Data Mesh is the data version of this. Because Pipelines and Data Lakes are a generic separation technologies instead of being DD bound
• Decomposition strategy (search slack)
• Another aspect of this is that separating logic based on business domains is better because business changes usually cut across technological implementation and usually don’t care about the concerns and separations s of the technology.