自从看了
我还是比较习惯三层架构/或其变体这种编码习惯.但是到了后期发现一个庞大的项目后期维护起来真的很恶心.事务脚本有一个状况就是我一个功能要修改.我不知道具体哪个类哪个方法对应这个功能,而active record呢,在涉及到多个表的先后操作感觉又有点奇怪.感觉这个方法不应该放在这里,但是又不知道该放在哪里.
而我所理解的领域驱动设计,是一种建模的思想.这种思想把方法的布置放在一个领域对象中.领域对象对我来说就是一个抽象的名称类型.比如消费者,服务提供者,订单,各种交互图中的对象.比如有一个银行家领域对象,无产阶级领域对象,无产阶级找银行借钱就是在无产阶级类里面有一个借钱的方法,该方法的参数包含银行家对象还有一些需要的”手续”.我个人是不喜欢把领域模型弄的很充血的,因为好多属性需要在实例化的时候注入.方法一多怎么办?但是必要的主键id我还是会加上去的.
那么这个借钱的方法主体无非就是,我要根据这些手续判断借钱是否合法.而数据来源不在该方法获取而是作为参数.那么数据来源写在哪里呢?写在领域服务里的仓储接口里面.这样就没什么问题了.业务变更的时候,我们只要改这个借钱方法了,如果需要其他手续?我想到时会考虑把”手续”作为借款人的属性吧.
After reading
I’m still quite accustomed to the three-layer architecture or its variants. However, I discovered later that maintaining a large project is really painful. With transaction scripts, there’s a situation where I need to modify a feature, but I don’t know which specific class or method corresponds to this feature. As for active record, when it involves sequential operations across multiple tables, it feels a bit strange. It feels like this method shouldn’t be placed here, but I don’t know where else to put it.
What I understand about Domain-Driven Design is a modeling philosophy. This philosophy places method organization within domain objects. Domain objects, to me, are abstract named types. For example, consumers, service providers, orders, and various objects in interaction diagrams. For instance, there’s a banker domain object, a proletariat domain object. When the proletariat borrows money from a bank, there’s a borrowing method in the proletariat class. The parameters of this method include the banker object and some required “procedures”. Personally, I don’t like making domain models too anemic, because many properties need to be injected during instantiation. What if there are too many methods? But I will still add the necessary primary key id.
So the main body of this borrowing method is nothing more than: I need to judge whether borrowing is legal based on these procedures. The data source is not obtained within this method but is passed as a parameter. So where is the data source written? It’s written in the repository interface within the domain service. This way, there’s no problem. When business changes, we only need to modify this borrowing method. If other procedures are needed? I think I’ll consider making “procedures” an attribute of the borrower at that time.
После прочтения
Я все еще довольно привык к трехслойной архитектуре или ее вариантам. Однако позже я обнаружил, что поддержка большого проекта действительно болезненна. С транзакционными сценариями возникает ситуация, когда мне нужно изменить функцию, но я не знаю, какой конкретный класс или метод соответствует этой функции. Что касается активной записи, когда речь идет о последовательных операциях с несколькими таблицами, это кажется немного странным. Кажется, что этот метод не должен быть здесь, но я не знаю, куда его еще поместить.
То, что я понимаю о предметно-ориентированном проектировании (Domain-Driven Design), — это философия моделирования. Эта философия размещает организацию методов внутри доменных объектов. Доменные объекты для меня — это абстрактные именованные типы. Например, потребители, поставщики услуг, заказы и различные объекты в диаграммах взаимодействия. Например, есть доменный объект банкира, доменный объект пролетариата. Когда пролетариат берет деньги в банке, в классе пролетариата есть метод заимствования. Параметры этого метода включают объект банкира и некоторые требуемые “процедуры”. Лично я не люблю делать доменные модели слишком анемичными, потому что многие свойства нужно внедрять при создании экземпляра. Что делать, если методов слишком много? Но я все равно добавлю необходимый первичный ключ id.
Итак, основное тело этого метода заимствования — не что иное, как: мне нужно судить, является ли заимствование законным на основе этих процедур. Источник данных не получается в этом методе, а передается как параметр. Так где же записан источник данных? Он записан в интерфейсе репозитория в доменном сервисе. Таким образом, проблем нет. Когда бизнес меняется, нам нужно только изменить этот метод заимствования. Если нужны другие процедуры? Я думаю, что в то время рассмотрю возможность сделать “процедуры” атрибутом заемщика.