Your first step is to identify the layers into which your application can be divided. You want to be careful not to define lower-level objects. Be sure that each system object you define can stand alone. If you can create an object with clean lines of separation from other parts of the system, then it can be a system object. By keeping these objects as large as you can, your teams will be able to work independently for longer stretches of time. A system object must be large enough to justify a person or team working alone for some length of time. You also must be able to create a clean line between each system object. Think of your server objects as pots and your development teams as cooks. Sure, if the pot is big enough, everyone can stir in the same pot. It’s a lot easier if everyone has their own pot. A different development team works on each layer, and each team assumes that their layer exists on a different computer. This means that all communication between layers is over the network. Prevents "cheating" by accessing the implementation directly and allows for scaling because you can move a layer to a larger machine.
I like the idea of defining layers early but I've become comfortable of thinking in terms of the Port and Adapters architectual model. Can that be used in TBD? I'm thinking yes because each Port is a layer in TBD. I do think you might have to temper the "assume each layer is on a different computer" rule. For example, many systems I've worked on had the persistence layer baked into the core. One reason is to more easily allow for database transactions to span all the logic it needs to. I'm not sure it makes sense to place additional complexity into the system to make transactions span processes.
No comments:
Post a Comment