21–30 of 141 posts
[1] https://en.wikipedia.org/wiki/THE_multiprogramming_system
Surprising this has been written in 2017. It looks like java written a decade ago. This can be a kind of organizational solution much like microservices to separate concerns. This is important when collaborating with a large amount of people. Clear boundaries and all that. You pay for those boundaries with a convoluted mess of classes that describe the design pattern rather than the business logic. You end up with Ab…
Earlier quoted context omitted.
"presence of sql escape characters" - isn't a business rule. That's technical. Range acceptance - could defiantly be a business rule. Cross-field consistency - Could also be a business rule. I implement these rules both sides. Ideally i don't want an invalid command sent off in the first place. I also don't want badly implemented UI corrupting my business data. This way i can provide instant feedback to the user, and…
"I implement these rules both sides" ... and the maintenance overhead?
Adhering to dry in all cases, is not always the best solution. As the software community has discovered over the past years. Especially in relation to microservices.
In my software there's a bit of a disconnect between the application and interactors. As there is a message queue between them.
I've seen this a few times before, and it led me to believe that I was stupid. Comments like "...business rules simply don’t know anything at all about the outside world" left me wondering what components that DO know something about the outside world, actually know about the outside world? Turns out that the answer is a data access component might know where to find a database, and a client app might know where to f…
> Also, the concentric circles did nothing for my way of thinking, as messages are linear - they start from a place, and they end in a place. Thus a stack was a lot easier for me to digest than these concentric circles. Messages might be linear but scopes are encompassing inner scopes. Encapsulation is not usually depicted as a stack. > And finally, the ambiguous language. Why should I care that there are enterprise…
It can be, as concentric circles and stacks are isomorphic. What can be represented by one can be represented by other. Examples of dealing with scopes as stacks would probably be familiar to anyone working with C, C++ and other languages with stack-based local variables - your scopes there literally correspond to what's on a stack. Similarly, lexical scoping can be seen as a sequence (i.e. a stack) of associative containers.
(Hell, you can see concentric circless as a Tower of Hanoi viewed from top - i.e. a stack (albeit inverted in this case - I'd put the innermost circle at the bottom of the stack).)
I understand GP's pain because I too would prefer the same diagram as a simple stack of abstraction layers. But then again, such diagrams almost never work without corresponding textual explanation anyways, so it doesn't matter much how the diagram looks as long as the companion text is OK :).
Earlier quoted context omitted.
Superficial validation on things like form fields still occurs up in the UI layer before a Use Case is invoked. Additional validation is likely to happen in the Use Case as well. It's a ubiquitous thing so just like in any other app it should be happening at a few different points but the stuff validated in the Use Case is going to be related to the business rules it's trying to execute.
Hmm, how do you define "superficial validation"? Form field facultativity (better word?) cross-field consistency, range acceptance, presence of sql escape characters ... they can all be considered superficial, but also core business rule IMHO
Business rules does not mean what the business (bosses) dictates that the app should have.
Business rules the rules for the business domain.
Whether you should escape sql (or even use sql) is a technical/application concern, not a business rule.
A business rule would be something like "customers must get 10% discount if they bought more than 100 units" or "no employee should be allowed to have a salary bigger than their manager", etc.
I've seen this a few times before, and it led me to believe that I was stupid. Comments like "...business rules simply don’t know anything at all about the outside world" left me wondering what components that DO know something about the outside world, actually know about the outside world? Turns out that the answer is a data access component might know where to find a database, and a client app might know where to f…
> Also, the concentric circles did nothing for my way of thinking, as messages are linear - they start from a place, and they end in a place. Thus a stack was a lot easier for me to digest than these concentric circles. Messages might be linear but scopes are encompassing inner scopes. Encapsulation is not usually depicted as a stack. > And finally, the ambiguous language. Why should I care that there are enterprise…
Earlier quoted context omitted.
>My approach has always been to validate anything that crosses a trust boundary. That's a good approach unless a validation requires a db call with inner join (for example). This becomes too costly to do it 5 times (for example) just to get something written into db.
It remains a good approach, even in your scenario - because that perf problem is solved using a temporal cache.
A interface to define the validation aspect. 3 separate implementations of said interface : 1 for db lookup, 1 for cache lookup and last for unit tests. 1 factory method which return the instance to use depending of context. Another temporal cache that holds the instance of said interface (after all, you can never have enough caches).
And all of a sudden, validating some single shit takes +300 lines of code (plus tests). Welcome to enterprise , clean, better designed, greatly arhitected software everyone....
Surprising this has been written in 2017. It looks like java written a decade ago. This can be a kind of organizational solution much like microservices to separate concerns. This is important when collaborating with a large amount of people. Clear boundaries and all that. You pay for those boundaries with a convoluted mess of classes that describe the design pattern rather than the business logic. You end up with Ab…
> Surprising this has been written in 2017. It looks like java written a decade ago. Because good architecture has somehow evolved? > This can be a kind of organizational solution much like microservices to separate concerns. This is orthogonal to microservices. And microservices aint but one model of creating applications, not "THE 2017 model".
Of course. Every year gives us greater insight into what approaches work and don't work. Which is why we have seen Java technologies like EJB, JCA, JTA, OSGI, JSP etc generally fall by the wayside in favour of less convoluted and less architecturally heavy approaches.
> And microservices aint but one model of creating applications, not "THE 2017 model".
Microservices are unquestionably the defacto standard for most larger software development projects. Especially since they are intrinsically linked to the containerisation deployment approach which is a modern day concept.
At what point should basic validation be completed?
Field level validation(Is this email in a valid format) checking that input is sane is done at the UI level. Business rule validation(E.g student can't be assigned more than 10 courses) is done on the entities themselves. You put it on both sides to get the best of both. Instant feedback to the user, and on entities as last resort protection against a badly implemented interface.
In two places in UI: as close to the user as possible (which improves ergonomics) and at the system's border (which prevents entering invalid data to the system at all). While the former is somewhat optional, the latter is absolutely necessary and cannot be left to client-side JavaScript.