False Distinction In Code Between Business And Technical

MvcIsYagni is a concrete example of a more abstract idea:

: People often make a false distinction between "business" logic and "technical" logic.

In the end, it's all just code, and someone has to write and maintain it.

Hence, making arbitrary demarcations does nothing but create artificial forces.

Examples:

"Business (or "Domain") objects can know nothing about the database." Better solution: Listen to OnceAndOnlyOnce. If deduplicating database code can be done if an object knows nothing about the database, then put that logic elsewhere. Otherwise, leave it there.
"No {GUI code, HTML, ...} in the Domain Objects" Better solution: Listen to the UnitTests to tell you what code is most testable, and where.
...

In other words: All you need are the XpSimplicityRules. Anything else is, quite possibly, confusion.

This problem often arises when developers or architects make an early decision or assumption about the need for an n-tier architecture or some sort of layered architecture. When they make that decision, they then assume the need to follow all the related patterns and guidelines that are useful for such architectures (separating presentation from data, etc.) This reeks of BigDesignUpFront and PatternAbuse. See DontBeTooStrictAboutLayering.

Of course, the flip side of the coin, is that experienced developers, even XP developers, learn that domain objects work best, when they're just domain objects. In fact, all objects work best, when they have OneAndOnlyOneResponsibility?, and that is usually what drives the separation of objects. You don't have to leave it anywhere, if you don't make the mistake of mixing it with unrelated code. Believe it or not, but GUI, App, and Domain, are separate responsibilities, and those are just a minimum, and separating them, makes the code .. get this... simpler, not more complex. It isn't big design up front, or pattern abuse, it's pragmatic, and easier and less effort than not doing so. Any design that can thought up in a few minutes, on cards, can't be called big design up front, even by the most extreme XP'er.

Rather than saying something is always good or always bad, how about we identify when it is helpful and when it is not, and then let the reader weigh the sum.

While it is often efficient (in execution) to implement business logic down where, say, certain consistency assurances are implemented, it is well to identify such things as triggers that are there because "sales needs it" as opposed to those that are there because "not having this renders the database unreliable."

Even when they're not separated in layering, knowing where they are can be critical. It may be true that "it's all just code" but when business policies change, not knowing where the bodies are buried can cost an extra month or two (or three, as it happened) of just doing dependency forensics.

See SeparateDomainFromPresentation, FalseDistinctionBetweenBusinessAndTechnical