Return to Answer

The Entities have business rule classes, input and output interfaces that change together within the layer. The use cases know about that layer, and must change according to it's whims. And so must the business rules configuration classes (and tests, and logging, and ...). There are actually many things that slave to the inner layer but don't care about the rest of your application. This means grouping them together so they could be easily separated from the rest of the system is likely a good idea. The same can be said for each layer.

The Entities have business rule classes, input and output interfaces that change together within the layer. The use cases know about that layer, and must change according to it's whims. And so must the business rules configuration classes (and tests, and logging, and ...). There are actually many things that need the inner layer but don't care about the rest of your application. This means grouping them together so they could be easily separated from the rest of the system is likely a good idea. The same can be said for each layer.

But this one shows the flow of control in and out of layers. That's important here because the flow of control dictates the order of construction if your objects are immutable.

You can even use some DI library that will force you to separate construction from behavior code by making you write it in another language. You just don't have to.

But this one shows the flow of control in and out of layers. Note the purple arrow in the lower right corner. That's important here because the flow of control dictates the order of construction if your objects are immutable.

You can even use some DI library that will force you to separate construction from behavior code by making you write it in another language. You just don't have to.

Of course none of this dictates what you do with your transitive objects that pop into and out of existence as your program runs. Also, mutable objects are allowed to learn and retain references to objects that were created after them. That's how events work in the observer pattern. No, this is only about having the ability to construct a persistent (lives throughout the run time of the program), immutable (unchanging), object graph that can communicate from end to end yet still follow the dependency inversion principle so inner layers won't need to change just because the outer layers did.

Of course none of this dictates what you do with your transitive objects that pop in and out of existence as your program runs. Also, mutable objects are allowed to learn and retain references to objects that were created after them. That's how events work in the observer pattern. No, this is only about having the ability to construct a persistent (lives throughout the run time of the program), immutable (unchanging), object graph that can communicate from end to end yet still follow the dependency inversion principle so inner layers won't need to change just because the outer layers did.