Extreme Programming (XP) is one of the more well known Agile methodologies. It is a programmer-centric methodology that emphasizes technical practices to promote skillful development through frequent delivery of working software.This methodology takes “best practices” to extreme levels and that’s why its named as Extreme Programming. Code reviews are a good example of Extreme programming. If code reviews are good, then doing constant code reviews would be extreme; but would it be better? This led to practices such as pair-programming and refactoring, which encourage the development of simple, effective designs, oriented in a way that optimizes business value.
Extreme Programming defines 4 basic activities (coding, testing, listening & designing) and several practices like Pair Programming, Planning game, Test driven development, continuous integration, design improvement, coding standards, collective code, simple design etc.
Projects suited to Extreme Programming are those that:
- Involve new or prototype technology, where the requirements change rapidly, or some development is required to discover unforeseen implementation problems
- Are research projects, where the resulting work is not the software product itself, but domain knowledge
- Are small and more easily managed through informal methods
Below are some software development process based on a concept of Extreme Programming and are about how to approach your design.
Test driven design (TDD)
TDD is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. It offers them a technique to explore the concepts behind the customers requirements, questioning that requirement and uncovering likely pitfalls. The developer can deliver these benefits without spending valuable time building and perfecting a graphical user interface. it stops developers from over engineer the product and encourage them to think from different prospective.
TDD relies on the repetition of a very short development cycle :
- Write an automated test case that defines a new feature – no code yet, so test will fail
- Produce the minimum amount of code to pass that test
- Refactor the new code to acceptable standards.
Domain driven design (DDD)
DDD is the process of being informed about the Domain before each cycle of touching code. Domain is a set of functionality that you are attempting to mimic that lies outside of your application.Domain Driven Design (DDD) is about mapping business domain concepts into software artifacts.Driven Design (DDD) focuses on the core model (the domain) and tries to keep other stuff like UI’s and databases separate.Domain Driven Design is all about understanding the customer real business need and emphases focuses more into the business need not focusing on the technology.
It promotes important agile principles:-
- Maintain the projects primary focus on the core domain of the delivery
- Use models to refine a complex design and
- Get the key team members together to collaborate deeply to derive their designs.
Domain modeling and DDD play a important role in Enterprise Architecture (EA). Since one of the goals of EA is to align IT with the business units, the domain model which is the representation of business entities, becomes a core part of EA. This is why most of the EA components (business or infrastructural) should be designed and implemented around the domain model. Domain driven design is a key element of Service Oriented Architecture (SOA) because it helps in encapsulating the business logic and rules in domain objects. The domain model also provides the language and context with which the service contract can be defined.
Domain driven design effort begins where domain modeling ends.
There should be more focus on domain objects than services in the domain model.
- Start with domain entities and domain logic.
- Start without a service layer initially and only add services where the logic doesn’t belong in any domain entity or value object.
- Use Ubiquitous Language, Design by Contract (DbC), Automated Tests, CI and Refactoring to make the implementation as closely aligned as possible with the domain model.
From the design and implementation stand-point, a typical DDD framework should support the following features.
- It should be a POCO based framework.
- It should support the design and implementation of a business domain model using the DDD concepts.
Bounded Context is a central pattern in Domain-Driven Design and It is the focus of DDD’s strategic design section which is all about dealing with large models and teams. – for more details on bounded context continue reading ddd here – series 2 of DDD.
Behaviour driven design (BDD)
BDD is a software development process based on Test-driven Development (TDD), that combines the general techniques and principles of TDD with ideas from Domain-driven Design (DDD) and Object-oriented Analysis and Design to provide software developers and business analysts with shared tools and a shared process to collaborate on software development, with the aim of delivering “software that matters”.While it is a refinement to TDD, it concentrates in understanding the user’s behaviour, and yields nicely to a good acceptance of the end system. In the though process means thinking from outside the system in. The benefit is that it offers a more precise and organized conversation between developers and domain experts
BDD is also often heralded because BDD testing tools can be arguably more human readable to non-developers such as Domain Experts
Event driven architecture (EDA)
Command Query Responsibility Segregation Pattern (CQRS)