Catalog of patterns

There is a large number of patterns that people apply in agile software development projects. These might deal with the process being applied, with software architecture, modeling, building software, testing it, or even with the basics of all software development projects: how do people communicate and collaborate.

Project patterns¶

Pattern that help you execute projects better and more efficient.

Butcher model. Different accounting mechanisms.

Analysis patterns and design patterns¶

Our catalog of analysis and design patterns is listed here.

Name smart use cases smart. How to name your smart use cases.
Build by use case. Why you should build your software smart use case by smart use case.
Evolutionary architecture. Agile projects require a different style of software architecture - agile or evolutionary.
Start end. Things that start also need to end.
Absent present. How to import new, existing and removed instances.
Quick estimate. Create a smart use case estimate, without having to model the smart use cases.

Patterns in the software architcture¶

The patterns listed below are often used in our software architecture, and found their place in our frameworks (ADF):

Framework patterns¶

Patterns that facilitate framework development.

Layer supertype. Single type that ancestors similar types, such as DomainObject, Task or Repository.
Descriptor. Inheritable enumeration, as used in Actions or Tasks.
Bridge. Pattern separating implementation of services from its specification.
Dependency injection. Pattern separating implementation of services from its specification, by defining its configuration.
Manager. Pattern facilitating services to other framework and application types, such as BindManager, TaskManager, StateManager, ResourceManager, ValidationManager or LogManager.

User interface patterns¶

Patterns that allow for the realization of the user interface.

Model view controller. Basic user interface pattern, with lots of different implementations.

Process layer patterns¶

Patterns that support the implementation of a use case (or workflow) driven process layer.

Task. Pattern to implement smart use cases independent of each other.

Domain driven patterns¶

Patterns that support the implementation of a solid domain layer in a domain centric approach.

Domain object. Layer supertype for all domain objects, such as Customer, Product and Contact.
Domain model. Pattern describing model of all domain objects and their associations.
Value object. Small and simple object, such as Isbn or Email that is meaningful to the customer domain, and is used for validation, often as type of properties of
Smart reference. Domain object to capture all simple references in an application.
Repository. Pattern that describes classes responsible for fetching existing instances of domain objects.

Mapping patterns¶

A collection of patterns to support implementing a back-end agnostic domain layer, by providing state.

Wrapping or mapping. A collection of patterns to ensure a domain layer independent of underlying technology.
Domain mapper. Pattern for mapping one type of elements to another, such as for binding and persisting domain objects and user interface panels.
Internal state. Pattern implementing domain object internal state independent of the underlying technology, without having to perform additional mapping.
Data transfer object. Transfer mechanism for fetching domain object internal state from underlying services.

Data and service patterns¶

Patterns to provide the domain layer with state, from several back-ends, including databases, middleware, services and legacy systems.

Data gateway. Pattern that describes interaction between the domain layer and the underlying databases.
Service gateway. Pattern describing the interaction between the domain layer and the underlying services, middleware and web services.