Arjang, They've been building bridges for a lot longer than we've been writing software and it should not surprise anyone that there is a lack of empirical guidance for software development. In the early days a lot of bridges collapsed because the builder did it "his" way.
Actually a vary large number of enterprise-class software applications _are_ just a duct-taped hodge-podge of approaches. It is getting better and guidance is available but maybe not for your current business problem, yet. This is where lists, like this one, can be very useful. Discussing the problem and sharing implementation approaches can lead to better ways of doing things which eventually become "standards". -- Regards, noonie On 26 February 2010 12:05, Arjang Assadi <arjang.ass...@gmail.com> wrote: > I wish I could agree with that, but how does what we as software > engineers do differs from the building or bridge engineers, surely > they don't build bridges or building on what "they" perceive to be the > right way. > > Surely there must be some sort of canonical form to implementation, > otherwise we are not software makers and just duct taping hodge podge > together. Every (software) system will gravitate towards maximum > entropy and minimum order and the programmer's job is to stablised it > by imposing order and decreasing the entropy. Having a structure for > defining how a system should be implemented would reduce the number of > possible permutation and hence decrease the entropy. > > I believe a systematic approach to defining and implementation is > necessary other wise we are just adding to total sum of junk in the > world. > > Regards > > Arjang > > > > > > > On 26 February 2010 11:21, silky <michaelsli...@gmail.com> wrote: > > On Fri, Feb 26, 2010 at 11:07 AM, Arjang Assadi <arjang.ass...@gmail.com> > wrote: > >> what are the Tools/Methodologies to categorise/Implement business > >> rules in .net? > > > > Honestly, isn't *every* rule a business rule? > > > > Shouldn't you just handle it via, you know, development?! And then > > test it via unit testing? I don't understand all this timewasting > > rubbish about spec'ing it out in some language that you then need to > > test in-and-of-itself and then have that generate it in yet another > > lower language. > > > > You haven't solved anything with that approach anyway. You've just > > shifted your problem. It's good sometimes, it's bad sometimes, it's > > not an answer to the underlying issue that to implement "Business > > Rules" you need to: > > > > 1. Understand them > > 2. Know how to program them > > 3. Test them > > > > This is our job - this is the purpose of programming. Converting ideas > > into things, and things into useful things, working things, correct > > things, and fun things. > > > > > >> There are just too many combinations / degrees of freedom in > >> translating business rules into implementation, but surely by now a > >> more holistic has come to being, anyone knows where or how to find > >> them ? > > > > Yes - your brain. It is the translation mechanism. > > > > > >> Regards > >> > >> Arjang > > > > -- > > silky > > > > http://www.programmingbranch.com/ > > >
