I understand your point, but I really intensely dislike the term "business logic" when used as some sort of universal. A bunch of us write code that nothing to do with any "business logic", even if there is some other sort of set of workflow rules & design that need to apply.

I write a DAW, and we face two major fundamental problems:

1. most DAW users don't use many features, but they do tend to use different sets of features. So if you want to be useful to lots of users, you need a LOT of features.

2. the corollary of (1) is that there are, unlike in "business logic" applications, oodles of workflows in use, and the application needs to support as many of them as possible without friction or bugs.

I mean business logic in a very broad sense. You have your DAW and it does something. That's the abstract model. You could define what it does in a high-granularity sense (point 1), but you also need to define what it does at lower levels of granularity. What you define at those lower levels is still part of the the abstract model of the DAW. Hence it's "business logic". Whether you use a while-loop instead of a for-loop, that's not business logic but an implementation detail.

Programmers make a ton of "implementation detail" type decisions but they also make a ton of decisions that affect the abstract definition of the thing, and these I define as "business logic".

The point is there isn't really a "thing the program should do".

If you compare to e.g. some sort of data entry or data analysis UI, you can describe the process the user is intended to follow, and that defines your "business logic".

With creative apps, this "process the user is intended to follow" doesn't exist. We're not implementing the rules of an employer or a company, we're providing open-ended workflows for people who don't know what they're doing.

It's still "enter data/modify data" along with suitable UI/ux and views to enable that.

Of course a DAW can probably be viewed as a low code tool for programming sound - so implementing a DAW is more similar to implementing a spreadsheet - than using a spreadsheet.

Still, the user has a goal, a process of achieving that goal - and the software needs to support the process and achieving that goal - eg output a track.

The fact that there are many users, with different goals and processes - doesn't mean that it's not "business logic" both to "crossfade" and "shift pitch".

"Business logic" normally dictates the relative ordering and contextual legality of certain operations and data values.

This doesn't apply to creative apps. Do this then that, or that then this, or the other and then that and the other other, etc, etc.

> It's still "enter data/modify data" along with suitable UI/ux and views to enable that.

While I agree that this is technically true, I'm not sure anything useful comes of viewing things in this way. Undecided, but doubtful.

> Still, the user has a goal, a process of achieving that goal

This just isn't true. Talk to creative people. Even someone doing a task like audio mastering, which is not particularly creative, doesn't begin with a goal. Musicians typically have only a vague idea, if they have an idea at all, of what they are trying to accomplish. That will change over time as they work on a piece and the process coalesces into "I'm trying to ..." as opposed to the earlier stage of endless "let's try ..."

> "Business logic" normally dictates the relative ordering and contextual legality of certain operations and data values.

Wikipedia gives the following definition for "business logic"

> In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.

I (and i believe op) lean on the "domain logic" end when talking about business logic.

So the fader toggles bits in the raw data, but in a way that input and output is sound data that can flow through the application. Your DAW needs both the bit fiddling - and the "flow input through the fader and out to file" parts.

> Musicians typically have only a vague idea, if they have an idea at all, of what they are trying to accomplish.

I'm talking much more abstract here - "improve recording" is a goal - there's a current domain state, and the goal is to modify it in some way. I'm talking about user intent in interacting with the domain.

From the wiki quote:

> the real-world business rules

what are these for creative apps, and where do they come from?

> ... determine how data can be created, stored, and changed.

So you can record sound, store it in a "track", transform it to "mono" etc?

> ... It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.

You might store the sound as a wav, export it as an mp3 - the undo tree might be in SQLite...

Ed: might make more sense with the term "domain"; domain logic, domain rules.

Ed2: somewhat tangential, but see also the original model-view-controller-(user) paper - the user holds a mental model of data/objects in the domain - and the application holds raw data in ram/disk - the UI needs to bridge these two domains so that a user can "apply reverb" from the domain concept to the actual data model (modify a wav file).

https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-in...

It's true that it's a bit of an expansion of the word "business", but it doesn't really mean "something to do with commerce". It's just the parts of the code that handles the rules of the system that directly enable the user's goals, and not any of the auxiliary, supporting infrastructure. So for a DAW business logic is pretty broad, true, but it would be stuff like, faders or muting a track and the effect on the mix, whether you can copy-paste a snippet of audio, and routing audio through plugins. And not things like the file format of a project, or the code that interprets hardware interfaces.

this is a failure of abstraction. over time, the platform detail handling gets separated into the runtime (for example memory management, now cloud provisioning, my startup is a language that abstracts distributed state). the reason we get ahead of the abstractions is that software is so valuable that we will spend $100M to bring a product to market by force of capital and its worth it because historically the winner takes most, this is just economic imperialism/conquering and barely a level removed from physical violence. it is sad actually how self interested we all are, imagine the world if we could figure out how to cooperate!