in order to separate concerns of a system, reduce coupling, and to isolate the domain layer of a system. An enterprise software system indelibly has several common concerns. A user interface accepts actions from a user, data must be saved to a database, transactions must be managed to maintain integrity of data, and business logic must be implemented. The question arises of “where do all these concerns get implemented within a system.” If these concerns are flattened into the presentation layer, this can lead to brittle software where one change could trickle to several areas and possibly unrelated areas of a system, thus making maintenance a headache. Changes become unintuitive to implement and scattered across a system. Layered architecture is fundamental concept not original to domain-Driven design, but nicely complements the idea of separating the domain layer. Evans concisely states the essence of the pattern:
Follow standard architectural patterns to provide loose coupling to the layers above. Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application, and infrastructure code. The domain objects, free of the responsibility of displaying themselves, storing themselves, managing application tasks, and so forth, can be focused on expressing the domain model. This allows a model to evolve to be rich enough and clear enough to capture essential business knowledge and put it to work.
The typical breakdown of a system with layered architecture has the following layers:
- User Interface (Presentation Layer)
- Application Layer
- Domain Layer
- Infrastructure and Technical Services Layer (Persistence Layer)
A basic principle of layering is the dependencies between layers must exist in one direction, starting from the presentation layer downward. The domain layer contains most of the business logic and is mostly accessible to the other layers. Designing a behavior rich domain layer allows for
- UI to be free of business logic and available to concentrate on presentation logic
- Application layer to be thin, meaning it directs flow and delegates work to domain objects. It also addresses the concerns of transaction management, security and other enterprise services
- Infrastructure layer to focus of data related concerns such as connections to a database, CRUD operations that can be reused across various modules, and possibly ORM specific API calls such as a criteria query or abstracted SQL language (ejb-ql or hql).
Behavior-Driven Development (BDD) was first coined and introduced by Dan North, now of ThoughtWorks. BDD is an extension upon TDD and does not contest the fundamental values of TDD. Dave Astels, another strong proponent of BDD, explains that "Behavior-Driven Development is what you are doing already if you are doing Test-Driven Development very well." The core of BDD consists of focusing on the behavior of software and defining that behavior through executable specification. The motive behind BDD was that the users of Test-Driven Development tended to move away from focusing on behavior and a testing mentality would take over as tests were written.
An example of allowing a "testing mentality" to take over your test-Driven development process would be as follows:
- I create a test for class PersonService and its method findPersonByName, which is intended to retrieve a Person object whic has the name "bob" from a database. Note that I intend class to use a DAO of some sort to do data retrieval.
- I create the PersonService, Person, and PersonDAO class.
- Now I get back to my test and create my necessary mocks which may be for the Person and PersonDAO class. During this process I set up those mock objects to have dummy data or for them to expect invocation