Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Outside-In Design
Every element of a design is justified by a real step that real customers are going to take, either directly or indirectly. This outside-in process reflects other best practices in the software development world.
For instance, the technique of Programming by Intention (once known as Top-Down Programming) tells us to first define the interface of a method in the context of its use and then fill out its implementation. Likewise, the discipline of test-driven development teaches us to start by building a client (the test) and move on to building a class once we understand how it might be used.
In their appropriate domains, each of those techniques is so successful that nobody who knows what they are doing bothers to contest it anymore. Architecture is one of the last places where you don’t typically organize work outside-in.
Much of the power of value-stream-oriented architecture is in implicitly defining “outside” to mean “the value stream” and “inside” to mean “the pieces of your system furthest from customer interaction.” Once you have an “out” and an “in,” then you too can leverage the power of deriving implementation from use.
In addition, the simple designs generated by an outside-in approach have a really powerful side-effect: they are very easy to change. As many know and the rest will soon learn, responding to change is the name of the game in the software world.