A Theory of Software Architecture
danuker.go.ro
A Theory of Software Architecture
1–10 of 246 posts
Re: A Theory of Software Architecture
#2Move most of your code to pure functions, that is the number one mantra to solve most scaling problems in software development. Even in an OOP paradigm, it makes sense to make almost all objects as purely functional, with limited use of internal state.
The second mantra is to think a thousand times before you name something. I actually keep a list of names (..Manager, ..aggregator,etc.) gleaned from various sources, to name my classes. Earlier, I used to name most of my classes as Manager
Edit : Here is a question, that actually prompted me to keep a list.
https://stackoverflow.com/questions/1866794/naming-classes-h...
Re: A Theory of Software Architecture
#3So applied Onion Architecture. I agree with this part.
However, the functional part of the discussion, while I agree with its benefits, is highly depending on the domain within the onion.
Re: A Theory of Software Architecture
#4Move most of your code to pure functions, that is the number one mantra to solve most scaling problems in software development. Even in an OOP paradigm, it makes sense to make almost all objects as purely functional, with limited use of internal state. The second mantra is to think a thousand times before you name something. I actually keep a list of names (..Manager, ..aggregator,etc.) gleaned from various sources,…
Kill "Manager" of that list :). Adds to the naming burden (aka quality) by removing the fallback :).
I will adopt the list idea!!!
Re: A Theory of Software Architecture
#5Move most of your code to pure functions, that is the number one mantra to solve most scaling problems in software development. Even in an OOP paradigm, it makes sense to make almost all objects as purely functional, with limited use of internal state. The second mantra is to think a thousand times before you name something. I actually keep a list of names (..Manager, ..aggregator,etc.) gleaned from various sources,…
Scaling is not the only way to accomplish high-performance. In many cases performance can be achieved with stateful, imperative yet efficiently executed code that economizes on the use of resources on a single node. In many cases, such as for mobile, desktop, or on-prem deployments, this is the only way to "scale" since you do not have the luxury of increasing number of nodes on demand.
Re: A Theory of Software Architecture
#6Move most of your code to pure functions, that is the number one mantra to solve most scaling problems in software development. Even in an OOP paradigm, it makes sense to make almost all objects as purely functional, with limited use of internal state. The second mantra is to think a thousand times before you name something. I actually keep a list of names (..Manager, ..aggregator,etc.) gleaned from various sources,…
Pure functions are a good solution for a onion in a request / response pattern (which a lot of the scenarios are). However, an onion architecture representing something with state (e.g. a shadow Dom implementation), sometimes a OO inner core is the right solution.
Re: A Theory of Software Architecture
#7Way off the mark. "Software architecture" is about how you make the disparate parts of a software system work together towards a common goal. Most of these parts aren't code: hardware, programmers, tech support, HR, licensing and legal, etc.
Re: A Theory of Software Architecture
#8Move most of your code to pure functions, that is the number one mantra to solve most scaling problems in software development. Even in an OOP paradigm, it makes sense to make almost all objects as purely functional, with limited use of internal state. The second mantra is to think a thousand times before you name something. I actually keep a list of names (..Manager, ..aggregator,etc.) gleaned from various sources,…
Scaling is not the only way to accomplish high-performance. In many cases performance can be achieved with stateful, imperative yet efficiently executed code that economizes on the use of resources on a single node. In many cases, such as for mobile, desktop, or on-prem deployments, this is the only way to "scale" since you do not have the luxury of increasing number of nodes on demand.
I think the parent comment is talking about scaling in terms of software size, not performance.
Re: A Theory of Software Architecture
#9Move most of your code to pure functions, that is the number one mantra to solve most scaling problems in software development. Even in an OOP paradigm, it makes sense to make almost all objects as purely functional, with limited use of internal state. The second mantra is to think a thousand times before you name something. I actually keep a list of names (..Manager, ..aggregator,etc.) gleaned from various sources,…
> (..Manager, ..aggregator,etc.)
Names ending in Manager are usually a poor choice.
See Peter Coad's "-er-er" principle:
> The “-er-er” principle. Challenge any class name that ends in “-er.” If it has no parts, change the name of the class to what each object is managing. If it has parts, put as much work in the parts that the parts know enough to do themselves.
See also: http://www.carlopescio.com/2011/04/your-coding-conventions-a...
Re: A Theory of Software Architecture
#10Move most of your code to pure functions, that is the number one mantra to solve most scaling problems in software development. Even in an OOP paradigm, it makes sense to make almost all objects as purely functional, with limited use of internal state. The second mantra is to think a thousand times before you name something. I actually keep a list of names (..Manager, ..aggregator,etc.) gleaned from various sources,…
Agree on the functional bit.
Naming things: I try to not think about it for more than 10 seconds, and go with the best I've got by then. I find myself renaming things sometimes, and I'm eager to do this when a better name comes to me.