ECO...add creativity...

Model centricity ensures that your documentation remains relevant

Capture all the important facts in one place

An industry standard format - UML Exact and no room for

misinterpretation 10 years after the fact you can still

read it as if you had only written it last week

DDD brings the correct language to the developers

Do not optimize your language by reducing the number of words

It is a beautiful thing to communicate; why make it harder than it needs to be?

Your developers talking to stakeholders using the their own lingo is essential to avoid misunderstandings

After all you are considered the expert, make sure you are understood; learn the lingo and stick to it throughout the project, in the model, in the code, in the documentation, in the db-mapping

Database brand is just a flavor, choose one, try many

Database technology is mature As long as you keep in the middle of

the feature stream you can switch as you go along

Database manufacturers want to lock you in – make sure you keep a key to get out when you want

Do not shy away from reality, embrace change

Changing requirements is not necessarily the sign of an indecisive client, it is you getting more information

Tools like model evolution help you to feel good about new facts

Do not worry, the rapid fluctuation of requirements wears off as you home in on the truth; once there you are robust

Development is hard enough; focus only on the creative/hardest part

You do not have to maintain the database schema

You do not have to add extra fields to handle ordered relations

You do not have to write the domain objects with all their properties and associations

You do not have to write any persistence code

You only need to solve domain specific issues, more with your brain than with your fingers

The world consensus: layered architecture

Everyone agrees; keep business logic out of the UI since it makes the logic hard to reuse and maintain

The domain layer is largely maintained for you, just fill in your own behavior code

Where should we place the physical tiers? You are free to choose!

How should we communicate between tiers? Again you are free to choose

Focus on deliverable verticals, do not waste time on horizontals

Scrum & XP states that building software is a chaotic process and only fools try to predict everything needed to reach the yet to be determined goal

But at the same time you will end up with crap if you do not have a plan or architecture

Trust the framework for architecture and the chaotic process for requirements

Coding should be as straight forward as possible

Both ends of associations are always maintained

Change state is tracked automatically Lazy & eager load control Association objects with lifetime control Standard .NET model view pattern Search domain layer with OCL Search database with OCL Subscription mechanism to catch and react to

domain layer changes Domain layer transactions clears up ”execute &

verify” code

Your users expect undo & redo, why not just give it to them?

All professional apps have undo & redo

”It is not a problem to add it, but it will cost you”

Luckily the bluff is seldom called Undo & Redo requires a good domain

layer

Use the same domain layer for WPF, Silverlight, Winforms & ASP.NET

We make no assumptions regarding UI in the domain layer

We offer clear and easy access from all the UI techniques

Statefull & stateless models are supported

Reverse engineer an existing database

You have a legacy database already Reverse it to a model Shift focus and develop the model

instead of the database

Prototype the real thing

You can start a system based on the model alone

Autoforms Debugger with OCL-evaluation

Instead of hard to read logic use state diagrams

State diagrams enables you to ”draw logic” with triggers, transitions and guards

Transitions can have effects and update properties and create objects

Derived entities are common in all domains; accept it and grow

Derived attributes and associations give you easy to read code

Ability to use the same data in different aspects while keeping a normalized datamodel

Automatically maintained with subscription and lazy evaluation

Refactoring is not a big thing, but it is important.

To keep old things fresh you will need to refactor

With less man hours invested in the old code and fewer expected man hours in the new code you are more likely to actually do it

Support for model level refactoring

Do you really need ”the human factor” in the core of your system?

What is the business value of having the human factor near the things we all agree on and just expect to work? People are lousey at routine tasks; they

will always give it the ”personal touch” = bugs

Everyone agrees on how to do it right. We just made it for you

Patterns of Enterprise Architecture (Martin Fowler) sums up the basics

There is nothing controversial here There are choices, we expose these

as settings Parent or child map inheritance Optimistic locking or not Type on persisted identity

Quick unit testing requires aspect orientation and mocking

To speed up unit testing you will want to replace the persistence layer with a mock

The Service design pattern puts you in full control

Add your own services Replace existing implementations

What kind of bugs should testers expect?

Hand on heart – are you good at endless repetitive tasks? Do you have the same precision as a machine?

No more persistence or association bugs Attributes that do not persist as

expected Associations set and saved, but fail on

load Cascading deletes that do not cascade

Domain bugs are left up to you– not infrastructure bugs

Is this not true development?

Development should be a creative process

You turn user requirements into tools Stay clear of all the old ways of

working that could keep you busy without knowing what the supposed business value was

Will it really work?

It works for developers using all .NET languages, but we have templates for the following: C# VB.NET Prism (Delphi.Net)

Persisting their data in one of SQLServer MySQL Oracle Firebird, Nexus, SQLite, Xml An open API to add more

Will it save time? Is it fast enough?

It will increase quality Your resources can be focused on the

domain issues The gaming industry has accepted game-

engines ; and they live and breath performance. Do you honestly believe we have higher needs?

A normal part of the development cycle is to isolate bottlenecks and deal with them, now you will have more time to spend on this

There is no way back

Imagine the software developers at the starship Enterprise from Star-Trek. Do you think they hack persistence code by hand?

Good tools are addictive After using ECO you will never consider

using a less competent tool again, let alone no tool at all.

We will give you your money back if you are not satisfied (...Yes we will require the tool back...)

Your investment is safer than it ever was

Think about it; your investment is creativity and knowledge – kept in the industry standard UML format -> safe

Your behavioral code that uses the terms and facts from the model -> safe

Investments made in UI design – all .NET -> pretty safe

Was the future ever this bright?