Agile architectures [closed]

问题:

I am starting my graduate thesis and the subject will be "agile architectures"

Basically, it will start with a description of traditional software development methologies, and the subsequent birth of agile methodologies, finishing with recommendations and a design of a flexible application architecture easily adaptable to the inherent changes in software construction.

My question is, what patterns and design practices would you recommend for such an architecture? I'm interested in patterns that allow for maximization of class decoupling like dependency injection, high maintanability, and maximum abstraction from the specific problem.

回答1:

I recommend the following:

1. Repository Pattern
2. Specification Pattern
3. Dependency Injection
4. Domain Driven Design

Basically everything the ALT.NET crowd preaches.

回答2:

Definitely IoC practices and contract-based programming in general would be at the top of my list. From a matter of experience, though, I would caution against abstracting too much away from the problem simply for the sake of abstraction. E.g. abstracting because you can and not because anyone will ever be able to make use of that abstraction. I've seen that kind of architecture gone bad and simply add too high a degree of complexity to a system making maintenance of the system worse.

Some sort of feedback loop around your development process -- be it unit tests, continuous integration and/or "scrum" meetings. I realize that doesn't really fall into the scope of agile "architectures", but if you don't have and agile process, no degree of "agile-oriented" architecture will matter.

回答3:

An essential design practices I'd suggest is to build first a functional, end-to-end skeleton of your architecture. To validate it as early as possible by real feedback.

This is what the Pragmatic Programmers refers to as "Tracer Bullets", and Alistair Cockburn as "walking skeleton".

Can you also define what an application is in the context of your thesis ? Do you only consider application software or do you also deal with more complex systems ?

回答4:

It's an interesting question, this. Can an architecture be created agile in isolation? If we're looking at something like XP then I'm a little doubtful. Or maybe I've misunderstood, but that's never stopped me from expanding...

In XP, to take an approach I know more about, we're going to have some sort of structure within a very short time after we start a project; about the time the first story is complete, in fact. During the initial story-writing we'll have started to get some idea of what we might build - it's inevitable: programmers tend to think in terms of code. But thinking too far ahead takes us into YAGNI territory.

I kind of thought that much of the architecture of an application developed within an agile environment would be expected to be emergent through, in particular, constant and dedicated refactoring to remove duplication.

So perhaps the question is as much to assess if there are particular characteristics - or classes of characteristics - that architectures evolved as a result of an agile process will tend to display. And then I think it's going to depend on what kind of app we're building, although some of the principles already mentioned (a couple of which I even understand) must be likely.

回答5:

As far as I'm concerned Agile doesn't preach any "Architectures" as such. Agile is a methodology that is based on fundamental principles that effect project management, release cycles and general development practice but certainly not software architecture.

All of the software patterns listed here could be used using a strong waterfall process which is anathema to Agile development.

回答6:

Onion Architecture

example

回答7:

Being agile means that you embrace change, i.e. adopt to change in requirements and design decisions and accept refactoring etc.. many things "traditional" way would frown upon, since you are touching something that's working/previously agreed.

In methods like XP tries to keep the quality high by writing unit tests. Let's pretend we all agree on writing unit tests.

Now here's where you can introduce some architecture so the system is testable, or test-friendly, because not all systems are testable. For example, making middle layer callable and separate UI layer from business logic etc.

回答8:

If Robert Martin has anything to say about it (and he called the original Agile Manifesto meeting IIRC), then absolutely architecture has everything to to with Agility. The entire first section of his book Agile Software Development, Principles, Patterns, and Practices is about the SOLID architectural principles. This has been somewhat controversial in some quarters but I don't understand why. If your codebase is brittle and heavily coupled then it cannot be very open to change, which is the hallmark of agility. Conceptually separating process from code practice is a very un-agile thing to do.

Principle 1 of the manifesto: "We value individuals and interations over processes and tools."

Defining Agile "process" as an abstraction separate from the architecture of the codebase to me violates the spirit of this first principle.