Archive for the ‘TrueView tips’ Category

Multi-monitor support and popup Search Queries

Monday, August 10th, 2009

The latest release includes 2 very useful UI features:

Multi-monitor support

This option is specially useful when you’re demoing to others, and can be enabled from Tools->Options->UI Settings->Allow MultiMonitor Use. All subsequent windows will open outside of the Workbench, allowing them to be dragged to other monitors.

Popup Search Dialogs

Although drag & drop is very powerful, not all users are comfortable with it, instead preferring to select items from a list.  With this is mind, a new context menu item was added:

popup-search-dialog-for-entity-property

Selecting this will open a Search Dialog, where the user can query and select an Entity.  It also works for EntityList properties (multiple Entities can be selected in this case):

popup-search-dialog-for-entitylist-property

It’s also possible to pre-load the popup search dialog using Query Specifications.  See the section “Pre-filtered Search Query Dialogs” in the user guide to learn more.

Tips for Domain Driven Design and TrueView

Tuesday, June 2nd, 2009

Here are some tips for DDD newbies.  It’s easy to fall back to doing ‘what you know best’, so use these tips to stay focused. Hopefully your design skills will get better (and faster) as a result. :)

  1. Don’t start with the User Interface
    Instead of asking “How will the user solve this problem?“, ask “What is the problem?
  2. Design Domain Models, not database schemas
    Most business users don’t understand database schemas – so don’t make them
  3. Design your Domain Model incrementally
    Defining too much detail early on is the fastest way to get side-tracked
  4. Get constant feedback from your Domain Experts
    Take advantage of TrueView’s auto-generated prototypes to get instant feedback
  5. Separate business concerns from technical concerns
    Writing technical infrastructure code can be counter-productive during the modelling phase
  6. Unit testing wisely
    Focus on testing non-trivial behaviour and complex business logic, possibly using BDD
  7. Think agile, be agile
    Your clients don’t have time to wait, so don’t make them

You can read the detailed version here.

When should you use a Value Object?

Tuesday, May 26th, 2009

Whilst in the middle of writing about “Entities vs Value Objects“  I discovered this post by Dylan Beattie.

I’ve observed that a lot of DDD newbies get hung up on Value Objects, persistence, how to normalise the database, and other implementation concerns.

Value Objects stem from the actual domain problem, not from  persistence.  Read Dylan’s post to understand why.

Missing treenodes in Options/Preferences Editor

Sunday, May 3rd, 2009

If you were running a previous version of TrueView, you may find tree nodes missing in the Preferences Editor.

The fix is to remove  the old user settings.  Open this folder in Windows Explorer:

  C:\Users\<your user name>\AppData\Local\Evolving_Software_Ltd\

And remove all folders for the application that is affected.

The reality of UI mock-ups and DDD

Thursday, March 19th, 2009

Casey Charlton is writing a sample application using DDD.  His first step was to create a UI mock-up to reflect a user story :(

“What’s so bad about that?” I hear you cry.  Well, here’s the problem:

UI prototyping is great for defining how a person is going to solve a business problem.  It’s not great at defining what the problem actually is (i.e. the business domain).

I’ve seen this happen many, many times:

  1. Developer sketches UI, to start discussions with the Domain Expert/Business Analyst
  2. Business Analyst adds/removes/repositions some widgets
  3. ‘Hand waving’ and ‘pointing at imaginary boxes’ becomes the communication technique of choice
  4. Developer agrees to ‘quickly code up’ an interactive prototype
  5. End user wants a different shade of blue

Although the Developer has good intentions of leveraging DDD, the urge to see working apps overrides everything else – leaving the Developer with a vague understanding of the business domain.

As the Developer does learn more about the domain, he usually finds that the original UI design is inadequate. And changing a UI is expensive (it’s a pity that most businesses don’t understand why).

This is where TrueView shines.  It automatically creates interactive UIs, but only based on domain definitions and relationships. Which means:

  • The Business Analyst must describe the business domain.
  • The Developer must start understanding the domain
  • Both must define and share the Ubiquitous Language.

TrueView doesn’t give you a totally customisable UI, but you do get an interactive prototype that models the business.  Once you understand the domain model, you’re in a perfect position to design a slick UI.