4 ms·

Thanks a lot for your comment. Is "attempting to keep track of business rules in a system other than your code base will cause more problems than it will solve"

Thanks a lot for your comment. Is "attempting to keep track of business rules in a system other than your code base will cause more problems than it will solve" true even if you track business rules only on high level? I.e. let's say that such auxiliary system does not track how often certain check is performed, but it does inform that such checks exist? In my case that means that we periodically check your website to see that the webpage targeted by the campaign is still up and containing certain information - do you feel like capturing such data outside the codebase is hopeless?

briandoll 16y ago
What is likely very valuable is understanding at a high level, the intent of your rules. For example, you might say that you verify the relevance of your campaigns. How you verify that will change over time, but the business value is that you verify them somehow. Then, instead of thinking of them as documented business rules, you can see them as marketable values your service provides. I've built several eCommerce back-ends, for example, and they each had a ton of very specific rules that were unique to the businesses, the products they sold, and the type of customers the services targeted. If you want to know precisely how the site validated address and credit card information, you'd really need to check the code. However, you could certainly say (and market) that you provide security measures to prevent fraud. The snag to avoid is attempting to document the specifics of the rules anywhere but the code itself.
- evaldas_a 16y ago
  One more question - so if we agree to keep the documentation within the code, are there any rules outside of using MVC / choosing good naming conventions that would help to undestand what's going on for somebody who is knew to the project? I.e. right now the only way a new developer can find out that we create invoices upon campaign deactivation would be by doing search in project files for instances where invoicing module is called. Is it possible to have some auto documenting system which could list all files w/ line numbers where specific function is called?
  - briandoll 16y ago
    The best way for a new developer to get to know the domain model and to understand the business rules is to read through the test suite first. From there the new developer may read through the implementation of the domain objects, controllers, etc. This assumes, of course, that the application is well designed, continually refactored and well tested. Every app has skeletons in the closet, though, and this perfect world often leaves something to be desired. If your code is relatively clean though, you'll have one and only one place where you instruct an account to be invoiced, and you can trace through that code anytime you have questions about how that scenario works. Suggestion: Every time you go diving into the code to investigate some scenario and wish to discover the business rules, start by writing a test for it. Write tests that expect that behavior, then execute the scenario and ensure your tests pass. Better yet, write those test first and you're all the way there. :)

briandoll 16y ago

What is likely very valuable is understanding at a high level, the intent of your rules. For example, you might say that you verify the relevance of your campaigns. How you verify that will change over time, but the business value is that you verify them somehow. Then, instead of thinking of them as documented business rules, you can see them as marketable values your service provides. I've built several eCommerce back-ends, for example, and they each had a ton of very specific rules that were unique to the businesses, the products they sold, and the type of customers the services targeted. If you want to know precisely how the site validated address and credit card information, you'd really need to check the code. However, you could certainly say (and market) that you provide security measures to prevent fraud. The snag to avoid is attempting to document the specifics of the rules anywhere but the code itself.

evaldas_a 16y ago
One more question - so if we agree to keep the documentation within the code, are there any rules outside of using MVC / choosing good naming conventions that would help to undestand what's going on for somebody who is knew to the project? I.e. right now the only way a new developer can find out that we create invoices upon campaign deactivation would be by doing search in project files for instances where invoicing module is called. Is it possible to have some auto documenting system which could list all files w/ line numbers where specific function is called?
- briandoll 16y ago
  The best way for a new developer to get to know the domain model and to understand the business rules is to read through the test suite first. From there the new developer may read through the implementation of the domain objects, controllers, etc. This assumes, of course, that the application is well designed, continually refactored and well tested. Every app has skeletons in the closet, though, and this perfect world often leaves something to be desired. If your code is relatively clean though, you'll have one and only one place where you instruct an account to be invoiced, and you can trace through that code anytime you have questions about how that scenario works. Suggestion: Every time you go diving into the code to investigate some scenario and wish to discover the business rules, start by writing a test for it. Write tests that expect that behavior, then execute the scenario and ensure your tests pass. Better yet, write those test first and you're all the way there. :)