场景 1：我们有一个两层关联，在 ActiveRecord 里面这样写：
orders = Order.where(id: [1,2]).includes(order_items: :product)
在 Lotus 里应该怎么写呢？按照官方的教学，查询应该直接写成一个方法：
order_repo = OrderRepository.new
orders = order_repo.find_with_order_items_with_product_by_id([1,2]) # => Array
但是问题来了，order_items 和 product 的关联是写在 OrderItemRepository 里的，OrderRepository 怎么知道存在这个关联呢？
为了保持 OrderRepository 的纯洁，我们只能把脏活交给 Controller 干：
order_repo = OrderRepository.new
orders = order_repo.find_by_id([1,2]) # => Array
order_items = OrderItemRepository.new.find_with_product_by_orders(orders) # => Array
order_repo.bind_order_items(orders, order_items)
数据总算是取出来了，可是 order_items 和 order 的关联弄丢了，没关系，我们再用一个方法补上。
取数据的部分完成了，看上去干了不少（？），但是总觉得怪怪的，Repository 的读逻辑往外层移动了，而且很难界定各部分逻辑应该由哪个 Repository 完成。
=======
场景 2：我们要创建一个聊天，并加上一条回复，其中涉及到三个表的关联，在 Rails 里这样写：
conversation = Conversation.new
reply = conversation.replies.new(message: 'xxx')
params[:attachments].each{|x| reply.attachments.new(file: x)}
conversation.save
在 Lotus 里，必须写成：
reply = Reply.new(message: 'xxx')
attachments = params[:attachments].map{|x| Attachment.new(file: x)}
ConversationRepository.new.create_with_reply_with_attachments(conversation, reply, attachments)
class ConversationRepository < Hanami::Repository
def create_with_reply_with_attachments(conversation, reply, attachments)
conversation = create
reply.conversation_id = conversation.id
saved_reply = ReplyRepository.new.save(reply)
attachments.each do |att|
att.reply_id = saved_reply.id
AttachmentRepository.new.save(att)
end
end
end
#其实真正lotus的repository是没有save的，我这里假装可以save entity，避免了传hash参数，如果是hash参数的话repository会承担更多的逻辑
为什么要把 reply 和 attachment 的数据都传到 create_with_reply_with_attachments 里呢？因为在 create reply 之前，attachment 不知道 reply 的 id，是不能保存的。所以你必须自己在 create_with_reply_with_attachments 里按顺序保存数据。
但是其实我们的 ConversationRepository 并不应该有 Attachment 甚至 Reply 的知识。这样的后果是，要么 Repository 变得越来越肥，要么是你还得像 Rails 一样，把 create 的逻辑写到 controller 里，这样 Repository 又再一次被架空了。
=======
以上两种场景都会有些逻辑的异位，不知道有什么好方法避免？
按我的理解，Repository 的正确用法应该是：
data = repository.query # complex sql
service.process(data)
repository.commit(data) # complex sql
其中 process 不操作数据库，只在内存里处理 entities，但是 query 和 commit 的 sql 其实都得自己写，而且这堆 sql 不知道如何 SRP。大概最后也会变成薄 service，厚 repository。
一种想法是把 data 做成一个数据表的 diff patch，在 commit 的时候自动 apply，但是这其实就是 AR 的做法。。只需要在内存里构建好数据和关联，然后 save 就够了。
讲一下个人理解 Repository 的用法，不一定是 Lotus 最好的用法。
逻辑上以 Repository 和模型一对一（不一定是一张表），多个 Repository 支持一个 Service 操作的方式区分代码职责。比如
Order.where(id: [1,2]).includes(order_items: :product)
拆分为
class OrderService
attr_reader :order_repository
attr_reader :order_item_repository
attr_reader :product_repository
def initialize
@order_repository = nil
@order_item_repository = nil
@product_repository = nil
end
def list_with_item_and_product(id_list)
orders = @order_repository.list(id_list)
# fill orders with items and products
# from order_item_repository and product repository
end
end
controllers 不处理类似代码，因为不利于代码复用。 第二个场景也是类似的方式。
class ConversationService
attr_reader :reply_repository
attr_reader :attachment_repository
def initialize
@reply_repository = nil
@attachment_repository = nil
end
def save_reply(message, attachments)
# validate parameters
# begin transaction
reply = Reply.new
reply.message = message
@reply_repository.save(reply)
# create and save attachments
# end transaction
reply
end
end
遇到类似的代码职责问题可以通过建立一个中间层来解决（但是记住不能建太多），这里实际上是一个业务逻辑层。
Rails 自身在设计的时候有意忽视了这点（因为目标客户的原因），把 Repository 和模型合并（后果就是在没有数据库的时候你无法测试），预期 Controller 中不会有太复杂逻辑，采用了一些不是最佳的代码复用手段。理解这点后，你就可以不拘泥于 Rails 的设计而按照常规的软件架构（不仅仅是 MVC）进行设计和编码。
以上仅作参考。
先粘贴两个链接，不知道 lz 是不是需要：
然后说点题外话。实际上我觉得写代码就是 3 件事：实现功能，去除重复，最后使表达清晰——主要是命名。
但是在完成后面两个目标的时候，特别是是“去除重复”这个目标的时候，我们会不断的遇到困难。这时候就不得不动用你所在的那个世界（那门语言）所能提供的所有方法资源：封装、组合、继承、mixin、元编程等等。
极端地去除重复必然导致模块粒度细化，各种最细粒度的模块互相结合又成为更粗粒度一些的模块，最后软件成为各种不同粒度（不同抽象级别）组合而成的一个组合体。它的内部因为没有重复而条理清晰。似乎很多写不干净代码的人会嘲笑这种情况只是个梦。
所以，我觉得没有必要去纠结太多概念，也没有必要迷信各种框架的写法。有了原则，什么都好办，没有太多固定的模式。
其实以我自己的一点经验，多写写脱离现有框架的东西。比如公司项目里看似比较边缘的，跟整体框架关系不是很紧密的，又没有现成框架可用的东西。把那些东西写干净的话，对自己的提升其实比在一个框架（比如 Rails）里写代码来得大得多。
希望以上这些能有点帮助。