Random Notes
This book is divided into four sections.
- Application layers MVC and DDD drives us towards an initial application architecture. In this section we would look at what are the implementation issues we need to deal with. Here we would supplement our initial layers of architecture with other layers, clearly defining their responsibilities. We would look at dependency between these layers and style of interaction between them. Instead of laying down the final picture, we would evolve the architecture, from the starting point, by picking concrete examples and see how it affects the architecture. We would end the section with a final application architecture which would pick up for other sections in this book.
- Application modules All applications grow in size as it provides more features to its users. This leads to increase in complexity of the certain layers in application. This section deals with this problem, offering domain modules as a approach to keeping the application simple.
Contract design for an application service. - System of applications Approaches to partition a system into different applications and an application into various modules.
- Testing Designing interaction between layers in an application and modules in an application.
This book would attempt to explain all concepts/patterns with source code. I am assuming a relational database based system. Since in this book I would explain why, the concepts could be useful in other kind of systems as well. I am using Java as a programming language in order to reach out to most people. I would be sticking to familiar architecture and tool set to keep things simple.
I would take the reader through layers within an module, modules forming an application and applications forming a system. There are two ways I contemplated taking this journey in terms of levels of abstraction. First was to start from highest level which would be system view or from the lowest level, that is a single layer in a module. Instead I thought I start from somewhere in middle and expand both ways. So we would start with an application. This also seemed natural to me because this is similar to evolution we see when we start with a new product.
In this book we would take the example of a software system which enables the business of a small micro finance institution.
Anatomy and workings of an application
Every project needs define its layers, modules and building blocks.
All things not dependency http://www.tonymarston.net/php-mysql/dependency-injection-is-evil.html
You don't suffer because you haven't figured out the right presentation pattern (MVC, MVP, MVVM) but because you haven't figured out, how to handle view launching other view, handling modal windows, wizards, so on
Hide everything inside webcontext and keep your code independent of session, request, response. For testing create a derived test object and set data into for asserting the state
Build frameworks deliberately to separate all domain specific code from the functional code. The framework should be created in a way that any functional code on it should be easily unit testable. The development of framework should be associated with development of test utility if required.
The functional test should ideally test the behavior of the framework and not the functional code. Functional code should be testable