Red Hat dropped an article on 12 Factor Apps. Go take a look at that first. An illustrated guide to 12 Factor Apps | Enable Architect (redhat.com)
Now, download “The Method” from iDesign. Transform your software architect career (idesign.net) Filter: “Other” Look for “The IDesign Method.”
Reading through the 12 Factor App article, I see huge overlap with what Juval has been advocating for decades. Lots of this material is directly stated or covered in the onsite training for “The Method.”
Slicing apart components on the boundaries defined in the method takes cares of a large percentage of the suggestions.
Hiding data resources behind an accessor decouples persistence.
All cross-cutting concerns should be treated as utilities, shared by all components in the development stack. Message brokers are infrastructure services either baked into the host platform or run as a utility.
The Method foreshadows everything in the 12 Factor App, with the possible exception of a single code repository. I don’t want to rabbit hole on this idea but why does your app have to use a single code repository? There are legitimate reasons to avoid this approach: legal; geography; network isolation/latency; etc.
In the language design community, there is a push to make everything a service. Reference types and Value types can be services. The service could tell you the stored value, when it was updated/created, provide methods for manipulation, or any number of other things. There is no reason why we can’t do this. It’s already symbolically implemented in the Actor pattern.
Next, consider all communication as events. Calling a method is an event. Writing to disk is an event. Turning on an LED is an event. Something “happens” therefore it is an event.
Every value object is a service.
Every communication is an event.
How does this apply to 12 Factor and The Method?
I’m going to pick only on Point 11 of the 12 Factors to show how the Method is embedded in the 12 factor approach. If anything, it give guidance on how to actually deliver on the 12 factor app schema.
Treat logs as streams of events.
Why should this just be logs? Why are logs special in the larger application design? Honestly, they are not special.
All communications between objects are events. A “logging” event has a payload to describe the event. The event is posted to a channel where event subscribers can process the the event payload as needed. This is the exact same interaction model as a WCF channel managing RPC calls from a manager method to an interface implementation across component boundaries. This is all described in The Method.
Don’t get distracted by the details of the communication. The platform should make those details transparent to the developer. It doesn’t really matter if you use REST, Pub/Sub or Queues. All of these have cost/benefit ratios to figure out for your project.
For me, the important part is seeing how Juval’s ideas predate 12 Factor Apps.
Returning to logs.
If everything thing is an event why do we need a specialized logging model? We don’t!
All events fire across one of more channels. Symbolically, a log event is the same as an event requesting an action from another component. The subscribers to that log event can write the events: to a tiny debugging log inside the component context; an application level log on the device; a sql data store for security authentication; non-sql data lake for later analysis.
Do you see the possibilities with this approach?
Spend some time reviewing the 2 articles. Look at the 12 Factor diagrams, turn them sideways and see how Juval showed these same ideas over a decade ago.