Anchor

Much of this comes down to decoupling different aspects of the system: persistence (DB), domain logic (business rules), delivery mechanism (web, REST), presentation format, UI layout, etc. This aggressive decoupling enables one to isolate and test these different facets of the system individually. Of course, building this decoupling requires some effort, and one has to be careful not to over-engineer. As with many things, it is a balancing act.

And yes, you can do TDD with the UI; separate the UI logic (user actions, UI state, input validation, etc.) from the layout system (and don't try to test the latter automatically). The fun thing is that when the system is decoupled, you can test the user interface of a JavaScript web application without ever starting a real* browser, running a web server or spinning up a database. It is an interesting system design challenge to be able to run even your UI tests at a rate of 100 tests/second.

*A headless browser is not a real browser in this sense

[1] http://www.cnn.com/video/data/2.0/video/us/2014/12/09/lv-mcc...

[1] http://respondcms.com

I agree that the interactors make rather odd-looking OO classes, but I suppose the imperative nature of most requests to perform some logic make them less objects in that sense. This has the added benefit of seeing what the system does, just by looking the class names in the interactors folder/namespace.

We have been using this approach for a year now, with REST on top, and it so far has worked beautifully. The entities map naturally to REST resources and DTOs makes nice request and response classes.

Armed with CQRS (now I sound enterprise-y), the data storage is easy to work with using the same DTOs (the data storage and its interface do not know anything about the entities either). On the DB implementation level, we work on the DTOs, which are trivial to store to the database (even without ORM, although it does remove much of the boilerplate). Only one class - the entity repository - is needed to convert the DTOs to entities, and this only happens on create, update, and delete. Reads (due to CQRS) go directly to DB without instantiating any entities - neat. We also use 'unit of work' -pattern to abstract the notion of transaction on create, update, and delete operations, which simplifies the interactor code, hiding the nature of the data storage (making it a swappable in this respect too).

But to stay on topic, our tests are fast too as the interactors can be tested by injecting an in-memory database as a data storage to test the business logic, and the interactors have no dependencies on any frameworks, web or otherwise. Testing the interfaces makes BDD feel natural and also supports clear separation of the REST layer (the communication channel) and the interactors (business logic).

This assumes, though, that the best of the projects is worth building in the first place.

As for the requirements, you have to have a company, small enough when entering the program (can outgrow the entry requirements during the three years and still stay in), and it has to produce software (service or packaged).

I think it is a sad state of affairs that it is indeed so in the modern world.

It is also interesting that it happens in so many distinct areas. Perhaps it is a property of the society and how it is structured today. It is of course rare for a community of nonprofessionals to be able to build a complete modern house. Why this affects musicians too, is not clear to me. The rise of individualism maybe?

I bought the whole The Nature of Order series five years ago and have been ever since trying to find a person who has read it. A have returned to the books periodically, and again and again feel the same excitement that prevents reading too much at one sitting. I have not yet encountered another book that does the same.

In fact, I feel the same way about writing this reply. It is as the implications of the book are too - how should I describe it - something to be spelled out; somehow I do not feel I can do justice to the text by discussing it. I do not even know where to begin.

Perhaps it is best summarized by saying just read it. Yes, this is a lousy book review, and the price tag is not of the average variety, but this is a series of books for (of) life.

920 seems to live up to the promise also in this regard.

  static void Main()
  {
    Bar( 12, 15 );
  }

  static void Bar( object o1, object o2 )
  {
    Foo( o1, o2 ); // error
  }

  static void Foo( int x, double y )
  {
    Console.WriteLine( "int double" );
  }

  static void Foo( double x, int y )
  {
    Console.WriteLine( "double int" );
  }

  static void Foo( double x, double y )
  {
    Console.WriteLine( "double double" );
  }

  static void Foo( int x, int y )
  {
    Console.WriteLine( "int int" );
  }

He is definitely on mine.