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?