Agile and Domain Driven Design

Issues with Agile include scaling and not having a detailed design which considers all aspects of security, interoperability and networking. OOAD and Domain Driven Design can help alleviate these issues.

Agile

Agile is not only a delivery method of course, but an approach to project management and deployment. Agile stresses Proof of Concepts, sometimes called ‘Minimum Viable Product’ or MVP, which are hands-on attempts to assess technologies, concepts and first designs. The design process is never ‘skipped’ in Agile, it is just not as formalized and sequential as the Waterfall theology. MVPs or POCs are practical attempts to see what works, and what does not. They are not the theoretical models of Waterfall liturgy, but rational attempts to investigate if the chosen technologies, platforms, or services, do actually work in real life.

Design

In any IT project, even a migration, you cannot escape Design. The main issue is how to build the design. You can employ the ‘big detailed design up front’, as demanded by Waterfall theologians. Or, you can do it incrementally as real-world Agile projects reveal. This means using a High Level Design to initiate Agile development processes, and over time, as you come to understand the technologies, services, existing platforms and target platforms; an End-to-End design.

Why Waterfall design fails

Waterfall emphasises the complete End to End design of any system before a stage-gate is signed off, and before any development resources are deployed. The following are problems with this approach:

• You will have development resources doing nothing but eating up budget, whilst they await various bureaucratic approvals.
• Your Project Managers will produce great volumes of useless Top-Down Gantt charts, astrologizing into the future, what your technical team will be busy with 6 months hence. There is no possibility of planning an IT project in such a way. Instead POCs and MVPs will indicate how much effort by technical area is reasonable to plan for; what resources and level of skills are needed; and how much time and budget it will take.
• Cross functional teams are not set up within Waterfall – they are usually ‘technically led’ and ignore domain considerations, or worse they are Project Management led ensuring project failure and cost over-runs.
• Technology choices are imposed on the project, which is the opposite of what should be done. You need to determine what functionality you are building or replacing and then configure a probable solution. You can only do this with hands-on assessments.
• Waterfall assumes that the current estate is well-known and documented, and that the target model is simply a deployment issue. This is not true. Most current estates are undocumented and need to be discovered by the team that is deploying to the target model. Otherwise you will make incorrect technology and resource choices. Target deployment platforms are often complex or unknown and take a period of discovery, based on MVPs or POCs to clarify.

Your design always changes as you do more hands-on. You will find that the original high-level design is imperfect and needs to change. You will discover that certain technologies are not a good fit. Iterative hands-on POC/MVP work is the only way to discover this. In general, the Waterfall cult, impelled by barely IT literate Project Management, will construct a ‘big’ End to End design that has little connection with reality.

Design Issues with Agile

A key problem within many Agile projects is that the deep thinking about design can be ignored to produce more features. Time and budget pressures usually coerce engineers into adding features or functionality and discourages the important aspect of overall system design, including issues around security and interoperability. In this environment, engineers do not give full consideration to data, behaviour or integration issues. The code and related databases become the focus of attention. Business logic, business processes, domain requirements are ignored in the rush to produce an MVP to impress management.

Common design issues in Agile include:

• Processing logic is implemented in the UI
• Data Persistence is mixed in with Processing logic
• Databases become encumbered with slow, locking queries
• Stateless architectures are eschewed for stateful
• Services become coupled together
• Code is produced but not tested properly and is fragile

Domain Driven Design (DDD)can help

DDD can help alleviate some of Agile’s design weaknesses. DDD encourages an iterative process of collaboration to explore a model and develop a shared language between development teams and domain experts. Business Logic or ‘Domain Logic’, is embedded into the process at its inception, where processes, workflows, functionality and entity relationships are determined. This domain driven approach is not top-down, abstract, nor does it ignore iterative POCs. It does however force the separation of logical layers and ensures that the Business Logic, not the UI, is the key aspect of development.

Key aspects of DDD:

• The domain (eg. Financial System) has sub-domains (eg AP, AR, GL etc).
• All domains and sub-domains are bounded and contained, or in other words, understood to contain specific processes and logic.
• Bounded contexts are used by Engineers to build the logic, code and databases.
• There is thus a unity of strategy and implementation across the Domain and sub-domains.
• Design is built across the Domain and sub-domains starting from the beginning of the project.
• Iterative POCs or MVPs are used to modify the designs including interoperability between sub-domains.
• All designs including sub-end to end designs use a common language and common data dictionary.
• Development is divided up into service based functional pieces, not monolithic coupled systems.
• Key Architectural principles are deployed across the Domain including the use of standard APIs; de-coupling; stateless systems; persistence of data; high availability; encryption of all data; SSO; backup and recovery. All designs must conform to the principles or have an Architectural Review Board exception approval.
• Individual cross functional teams use Scrum or something similar to communicate, set up sprints and work targets, produce MVPs and POCs and collaborate.
• Individual teams and subject matter experts, identify technical details including aggregates with values, entities, services, events and modules / components.

Building a proper design is not easy. The above assumes a proper budget, resourcing and coherent management structure. A management structure to scale Agile over 3-4 project teams (20+) people, takes thought and skill. Each team needs to be self-contained, cross-functional and be trained in Agile, dev-ops concepts and associated technologies (eg. Jira, CI/CD etc). This is not trivial.

Benefits:

DDD comes out of OOAD (object oriented analysis and design). DDD breaks systems within a bounded Domain, into components, objects, and functional services. It leads to micro-service architectures, including containerisation. Agile led DDD will give you a better, more coherent and detailed design, premised on Domain Business Logic. Events, services, technologies and target platforms will be assessed and discovered in an iterative fashion, recursively modifying the original design. Key architectural principles including security, decoupling and redundancy will be deployed throughout the design. Lastly, the use of MVPs and POCs will lead to a great improvement in finishing the project on time and on budget.