These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents
Max has the challenge that there are a lot of architectural decisions that have to be made. But how can his team make good decisions with only limited knowledge because they build the software incrementally and need decisions early to start developing?
These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents
When we build software with an agile approach, we build features incrementally and iteratively.Incremental = one feature after the other.Iterative = we build the first version of a feature, get feedback and improve it in the next iteration.
These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents
Max knows that the goal of the software to be built is to match potential team members based on their skills to a team. But that is not enough knowledge to start designing a software architecture.
These are the slides with some notes from my talk about software architecture when developing in an agile way.
This blogpost is part of a larger blog post series. Get the overview of the content here. Start early with an automated deployment. It will safe your ass! But try to keep it as simple as possible. If your deployment gets to complex this usually indicates that your “thing” decomposition is also too complex. Tools like Octopus Deploy or the Deployment Manager from Redgate help to visualize and monitor the deployment process to multiple environments. Keep in mind that managing the configuration...
This blogpost is part of a larger blog post series. Get the overview of the content here.
Speaking about trade-offs. You’ll face some challenges regarding decomposition. But rest assured composition isn’t a piece of cake either. There are a number of challenges you’ll face and I’m sure there are even more I haven’t discovered yet. But surely you’ll tell me when you stumble over one in your project, don’t you?
This blogpost is part of a larger blog post series. Get the overview of the content here.
The Composite Front End pattern glues “things” together as a cohesive whole still keeping them autonomous. The Composite Front End patterns takes the ideas of web portals and applies them to SOA. It is composed of two main components: the portlet and the host.
This blogpost is part of a larger blog post series. Get the overview of the content here. A frontend is not owned by a single “thing”. It is a mashup of multiple “things” combined together to provide a single user experience. Looking at it from the deployment perspective we can say that many “things” can be deployed to the same box, many “things” can be deployed in the same app, many “things” can cooperate in a workflow and many “things” can be mashed up in the same page. Which brings us...
This blogpost is part of a larger blog post series. Get the overview of the content here.
Immutable data is unchangeable once it is written. An immutable data needs an identifier which allows to always return the same data no matter when it is requested or where it is request. Immutable data can be found everywhere in the real world.
This blogpost is part of a larger blog post series. Get the overview of the content here.
Before we dig deeper into the characteristics of a “thing” we need to talk about the explicit boundaries of a “thing” and what contracts actually mean.