Mike Jerome michrome
| # 1. Add rack-rewrite to your Gemfile and run 'bundle install': | |
| # gem 'rack-rewrite' | |
| # | |
| # 2. Create a file with the contents below in config/initializers/asset_server_middleware.rb | |
| # | |
| # 3. Rename 'YourApp' below | |
| # | |
| # 4. In config/environments/production.rb and config/environments/test.rb, set: | |
| # config.serve_static_assets = true | |
| # config.assets.compile = false |
On Tue, Mar 12, 2013 at 1:26 PM, Martin Fowler martinfowlercom@gmail.com wrote:
The term pops up in some different places, so it's hard to know what it means without some context. In PoEAA I use the pattern Service Layer to represent a domain-oriented layer of behaviors that provide an API for the domain layer. This may or may not sit on top of a Domain Model. In DDD Eric Evans uses the term Service Object to refer to objects that represent processes (as opposed to Entities and Values). DDD Service Objects are often useful to factor out behavior that would otherwise bloat Entities, it's also a useful step to patterns like Strategy and Command.
It sounds like the DDD sense is the sense I'm encountering most often. I really need to read that book.
The conceptual problem I run into in a lot of codebases is that rather than representing a process, the "service objects" represent "a thing that does the process". Which sounds like a nitpicky difference, but it seems to have a real impact on how people us
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.