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:

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):

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.

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.

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.

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.

“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.