Brought to my attention. I like the idea, as long as it does not remove transparency, especially as it relates to real-life process and context. This is about software, with its inherent sometimes mysterious complexity, and I am always interested in making the software as near to real process as possible. So I thought: Can this be reapplied naturally at a process level? Examining.
Obscuring Complexity (Using Model Driven Software Development) in InfoQ
Key Takeaways
If done well, Model Driven Software Development can partially obscure some complexity, but you are going to have to treat the source code output as build artifacts and take ownership of the templates. Maintaining code generating templates is a kind of meta-programming that most developers are not used to doing.
Twelve Factor applications can truly achieve lower complexity, but only when integrated with mature or stable (i.e. boring) data stores.
You can lower complexity in microservice orchestration by building in some limited, cross cutting intelligence into the connectors, but you must be careful because too much intelligence creates the opposite effect.
You can write smaller applications when using a heavyweight framework, but beware that efficiency may suffer, that these kinds of services are harder to tune for performance, and that it may take longer to debug certain kinds of issues.
With reactive programming, you end up trading backend complexity for frontend complexity. .... "
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment