P of EAA: Data Transfer Object
Data Transfer Object An object that carries data between processes in order to reduce the number of method calls. For a full description see P of EAA page 401 When you're working with a remote interface, such as Remote Facade (388), each call to it is expensive. As a result you need to reduce the number of calls, and that means that you need to transfer more data with each call. One way to do this
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
Catalog of Patterns of Enterprise Application Architecture
Catalog of Patterns of Enterprise Application Architecture Last Significant Update: January 2003A short summary of the patterns in Patterns of Enterprise Application Architecture (P of EAA). These pages are a brief overview of each of the patterns in P of EAA. They aren't intended to stand alone, but merely as a quick aide-memoire for those familiar with them, and a handy link if you want to refer
bliki: Moving Away From Xslt
All of this site is written in simple XML documents and transformed to HTML. I find this works really well, and means I never have to worry about dealing with HTML formats. (Not that fancy layout is my style, as you can tell.) I've even written a whole book that way. For most of this time I've used XSLT as my transformation language. I've got pretty good with slinging XSLT around and getting it to
bliki: Is Optimization Refactoring
If you make a change to improve the performance of a program, is this a refactoring? I see optimization and refactoring as two separate things, even though they often use the same transformations, and a particular transformation you do to your program may be both. The reason I see them as different is because they have a different purpose. You do refactoring to make the code easier to understand,
P of EAA: Money
Money Represents a monetary value. For a full description see P of EAA page 488 A large proportion of the computers in this world manipulate money, so it's always puzzled me that money isn't actually a first class data type in any mainstream programming language. The lack of a type causes problems, the most obvious surrounding currencies. If all your calculations are done in a single currency, thi
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: Technical Debt
Software systems are prone to the build up of cruft - deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further. Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on t
Event Aggregator
Channel events from multiple objects into a single object to simplify registration for clients. 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 v
P of EAA: Class Table Inheritance
Class Table Inheritance Represents an inheritance hierarchy of classes with one table for each class. For a full description see P of EAA page 285 A very visible aspect of the object-relational mismatch is the fact that relational databases don't support inheritance. You want database structures that map clearly to the objects and allow links anywhere in the inheritance structure. Class Table Inhe
P of EAA: Single Table Inheritance
Single Table Inheritance Represents an inheritance hierarchy of classes as a single table that has columns for all the fields of the various classes. For a full description see P of EAA page 278 Relational databases don't support inheritance, so when mapping from objects to databases we have to consider how to represent our nice inheritance struc-tures in relational tables. When mapping to a relat
P of EAA: Concrete Table Inheritance
Concrete Table Inheritance Represents an inheritance hierarchy of classes with one table per concrete class in the hierarchy. For a full description see P of EAA page 293 As any object purist will tell you, relational databases don't support inherit-ance - a fact that complicates object-relational mapping. Thinking of tables from an object instance point of view, a sensible route is to take each o
bliki: Fluent Interface
A few months ago I attended a workshop with Eric Evans, and he talked about a certain style of interface which we decided to name a fluent interface. It's not a common style, but one we think should be better known. Probably the best way to describe it is by example. The simplest example is probably from Eric's timeAndMoney library. To make a time interval in the usual way we might see something l
Active Record
Active Record An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data. An object carries both data and behavior. Much of this data is persistent and needs to be stored in a database. Active Record uses the most obvious approach, putting data access logic in the domain object. This way all people know how to read and write their d
bliki: Duplex Book
Last week I got the newest book in my signature series: xUnit Test Patterns by Gerard Meszaros. I've been working with Gerard with it on and off for a couple of years, so I'm fairly familiar with its contents, but somehow seeing the physical copy gave me quite a shock. Somehow it hadn't dawned on me how big the book was - 883 pages, easily the biggest book in my series. On the whole I'm not keen o
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.martinfowler.com/apsupp/roles.pdf