bliki: Feature Branch
A feature branch is a source code branching pattern where a developer opens a branch when she starts working on a new feature. She does all the work on the feature on this branch and integrates the changes with the rest of the team when the feature is done. During the work, she may merge in changes confirmed by the rest of the team into her branch, in order to reduce her integration once the featu
bliki: Integration Test
Integration tests determine if independently developed units of software work correctly when they are connected to each other. The term has become blurred even by the diffuse standards of the software industry, so I've been wary of using it in my writing. In particular, many people assume integration tests are necessarily broad in scope, while they can be more effectively done with a narrower scop
bliki: Dynamic Typing
I've long been loath to write any contributions on the debate between static and dynamic typing in programming languages. This is one of those emotive topics where people seem driven to debate rather than listen. But since I've been asked a few times about it, I will contribute my personal experiences. I'm not trying to convince anyone of anything, but I hope someone finds some food for thought in
bliki: Bounded Context
Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships. DDD is about designing software based on models of the underlying domain. A model acts as a UbiquitousLa
bliki: D D D_ Aggregate
Aggregate is a pattern in Domain-Driven Design. A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be separate objects, but it's useful to treat the order (together with its line items) as a single aggregate. An aggregate will have one of its component objects be the aggregate root. Any references from outs
xUnit Test Patterns
If you go to junit.org, you'll see a quote from me: “never in the field of software development have so many owed so much to so few lines of code”. JUnit has been criticized as a minor thing, something any reasonable programmer could produce in a weekend. This is true, but utterly misses the point. The reason JUnit is important, and deserves the Churchillian knock-off, is that the presence of this
MachineJustification
I remember in my teens being told of the wonderful things Artificial Intelligence (AI) would do in the next few years. Now several decades later, some of these seem to be happening. The most recent triumph was of computers teaching each other to play Go by playing against each other, rapidly becoming more proficient than any human, with strategies human experts could barely comprehend. It's natura
bliki: Tell Dont Ask
Tell-Don't-Ask is a principle that helps people remember that object-orientation is about bundling data with the functions that operate on that data. It reminds us that rather than asking an object for data and acting on that data, we should instead tell an object what to do. This encourages to move behavior into an object to go with the data. Let's clarify with an example. Let's imagine we need t
bliki: Editing Publishing Separation
In my conversations with Thoughtworks project teams over the last year or so, a regular theme has been the growing impact of content management systems (CMS). They aren't usually seen as helpful, indeed there is a clear sign that they are becoming a worryingly invasive tool - used for more than their core purpose in such a manner that they hinder overall development. Amongst the other irritations,
Presentation Model
This is part of the Further Enterprise Application Architecture development writing that I was doing in the mid 2000’s. Sadly too many other things have claimed my attention since, so I haven’t had time to work on them further, nor do I see much time in the foreseeable future. As such this material is very much in draft form and I won’t be doing any corrections or updates until I’m able to find ti
bliki: Technical Debt Quadrant
There's been a few posts over the last couple of months about TechnicalDebt that's raised the question of what kinds of design flaws should or shouldn't be classified as Technical Debt. A good example of this is Uncle Bob's post saying a mess is not a debt. His argument is that messy code, produced by people who are ignorant of good design practices, shouldn't be a debt. Technical Debt should be r
bliki: Design Stamina Hypothesis
Is it worth the effort to design software well? From time to time I have indirect conversations about whether good software design is a worthwhile activity. I say these conversations are indirect because I don't think I've ever come across someone saying that software design is pointless. Usually it's expressed in a form like “we really need to move fast to make our target next year so we are redu
bliki: Alienating Atmosphere
There are many factors that lead to the troubling DiversityImbalance that we find in the software community. Some of these, like the problems in teenage education that discourages girls from STEM subjects is a long term problem where our profession can't play a central role in fixing 1. But one factor that comes down directly to us is the alienating atmosphere that hangs over the tech community. 1
bliki: Canary Release
Canary release is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody. Similar to a BlueGreenDeployment, you start by deploying the new version of your software to a subset of your infrastructure, to which no users are ro
Event Sourcing
Capture all changes to an application state as a sequence of events. This is part of the Further Enterprise Application Architecture development writing that I was doing in the mid 2000’s. Sadly too many other things have claimed my attention since, so I haven’t had time to work on them further, nor do I see much time in the foreseeable future. As such this material is very much in draft form and
Photostream 109
Rhine Valley, Germany 04 Jul 2016 10:19 f/7.1 at 1/125, ISO 100, Sony a6000 with 16-70mm, 55mm-e ©Martin Fowler
Catalog of Patterns of Enterprise Application Architecture
Enterprise applications are about the display, manipulation, and storage of large amounts of often complex data; together with the support or automation of business processes with that data. Examples include reservation systems, financial systems, supply chain systems, and many others that run modern business. Enterprise applications have their own particular challenges and solutions, and they are
bliki: Utility Vs Strategic Dichotomy
One of the steady themes I've seen throughout my career is that of the nature and importance of software development. A few years ago a prospect told one of our salespeople that “software is like sewage pipes, I want it to work reliably and I don't want to know about the details”. This is the kind of approach that Nicholas Carr talked about in IT Doesn't Matter. 1 On a contrasting note we've done
Temporal Patterns
Summarizes various patterns that you can use to answer questions about the state of an information in the past. These include questions of the form “what was Martin's address on 1 Jul 1999” and “what did we think Martin's address was on 1 Jul 1999 when we sent him a bill on 12 Aug 1999”. 16 February 2005 This is part of the Further Enterprise Application Architecture development writing that I was
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Photostream 112
