Hi Rockford,
I'm writing the question for you, but I'm really interested in the way other forum users work for designing BO's.
I'm fairly new to CSLA, but convinced that it is the right choice for the "command" part of our library. In the "Simple OOP Design question" post I read your answer on a question and as a "rookie" Scrum user I noticed the ending of the first sentence "... business use case (or story, or user scenario - which ever term works for you)".
Now, I'm not a purist, but reading the web on Agile, it would probably be seen as "blasphemy" to imply a use case being the same as a user story. Again, personally I don't care, but it made me wonder how does your design process work?
Do you design from customer artifacts like narrative documents, or do you use UML use cases, or perhaps user stories and specifications (as a ..., I want..., so that, etc.)?
Maybe the question isn't really within the scope of this forum, however, you being the creator of CSLA I can imagine that somehow you also had your design process in mind.
I'm hoping that you want to share your wisdom with the forum. I also bought the e-books today, so if the answer is in there, please let me know.
Cheers,
Peter
I think I tend to take an any-of-the-above approach. That is, if I can get formal requirements, I'll use them. But I'll also engage in conversations, or look at process flows, etc. My goal is to understand what needs to happen, and I find that sometimes comes through various means. In my company, IT doesn't have rigid standard on how to engage the business. The process typically looks different from project to project.
Hi Tim,
Thanks for sharing.
It sounds like the Specification-by-Example (SBE/BDD/ATDD) approach I read about recently. Collecting all possible artifacts that can help solve the problem. From your words I assume you're part of an IT department of a company?
I'm in the same position. I believe that this is a big plus as there is almostly no gap between business and IT, however, communication and understanding still can be difficult sometimes for both parties. Examples usually help communication a lot, as well as UI wireframes, Excel sheets, etc.
Recently I found a post by Steven Thomas on using Gherkin language to describe user story scenarios from a business rule point-of-view. It seems like an excellent way of closing the gap between business and IT, where both IT and business actually discuss and build (TDD) scenarios before actually programming stuff. As it is behavior driven this approach seems very well suited for applying to CSLA.
I don't know if this can be arranged, but it might be cool if this forum had a separate part for the design process of the business model.
Cheers,
Peter
Yes, we (IT) in my company have communication challenges from time to time with the business (i.e. sales, marketing, logistics, finance, etc.). But generally the same folks in various departments are involved in the discussions with same project/app leads in IT. Over time, many have learned how best to interact with one another to limit those communication missteps. So the multi-pronged approach has helped.
That is recognizable indeed.
I'm curious what your view is on TDD. Most of the posts written are usually in the context of IT being a separate company having several customers instead of a dedicated department having one "customer".
Just like you've written, IT starts to understand business and business starts to understand IT. So testing is almost always done from a business point-of-view, even by our IT. Next our colleagues are our forum, so the remaining exceptions are found by them.
Even though this works for us, I somehow find as if I'm missing out on something not yet using a TDD-like approach on our development. So again I'm looking in to it to see what I'm "not seeing".
Cheers,
Peter
We don't use TDD. Not because we are opposed, we simply haven't looked into it. There are only 4 devs (not counting the AS400 guys) in IT, and we maintain a wide array of active apps (VB6, WinForms, ASP.NET WebForms & MVC, WPF, SL, and soon WinRT). While we'd all like to learn and apply the best practices in many areas, we haven't taken the time to look at TDD. For that matter, we've only just started *talking* about including test projects in our solutions.
Our experience means we're likely never going to be great at one thing because we're constantly switching gears. I'm not thrilled about it, but limited time restricts our ability to learn and apply all the latest right ways of doing things.
Tim
Hi Tim,
I'm in the fortunate situation were I was able to create an "as-is" situation and delegate the current systems to my fellow developers. Now I can get my hands dirty on all the new stuff that comes along and hopefully find the ingredients for bring us to the next level.
In your post and some other posts from you I came across on the forum I've noticed that you are using a lot of different environments. I'm currently looking into the possibilities of creating a hypermedia API aka loosely coupled clients reading representations of resources versus an evolving (Web) API. Of course I'm not aware why you are working with all differents forms of environments, but it maybe its worth looking into. If a constant connection is a problem, I believe its even possible to create a selfhosting API, which is essentially the same thing, but without a hosting environment like IIS.
For now, enjoy the weekend :)
Cheers,
Peter
Copyright (c) Marimer LLC