ECO ...add creativity...

1. ECO ...add creativity...

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

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

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

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

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

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

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

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

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

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

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

13. Prototype the real thing • You can start a system based on the model alone • Autoforms • Debugger with OCL-evaluation

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

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

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

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

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

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

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

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

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

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

24. 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...)

25. 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?