Mixing Fowlers patterns I am developing a large .NET app.  The previous developer used Martin Fowlers Transaction script design pattern.  Please see the code below:

Public Class TypeStudent
    Private _Name As String
    Private _Type As String 'Undergraduate or postgraduate
    Public Property Name() As String
        Get
            Return _Name
        End Get
        Set(ByVal value As String)
            _Name = value
        End Set
    End Property

    Public Property Type() As String
        Get
            Return _Type
        End Get
        Set(ByVal value As String)
            _Type = value
        End Set
    End Property
End Class


Public Class Students
    Public Sub Add(ByVal typeStudent As TypeStudent)

    End Sub

    Public Sub Remove(ByVal typeStudent As TypeStudent)

    End Sub

    Public Sub Enrol(ByVal typeStudent As TypeStudent)
        If typeStudent.Type = "U" Then
            'Undergraduate specific logic
        ElseIf typeStudent.Type = "P" Then
            'Postgraduate specific logic
        End If
    End Sub
End Class


Notice that there is one Student class and Student.Enrol has to check the type of student before executing the appropriate logic.  Now please see the refactored code below, which uses a domain model approach:

Public Class Student
    Private Name As String
    Private Type As String

    Public Sub Add()

    End Sub

    Public Sub Remove()

    End Sub


End Class

Public Class Undergraduate
    Inherits Student

    Public Sub Enrol()

    End Sub

End Class

Public Class Graduate
    Inherits Student

    Public Sub Enrol()

    End Sub

End Class


Notice that Undergraduate and PostGraduate has its own implementation of Enrol.  I want to refactor more code so that it is like sample B to make it more reuseable and maintainable.  My question is; is it a bad idea to mix and match domain logic patterns in the same application i.e. part of the app written using Transaction Script and another part using domain model?
I don't think that there is inherently anything "wrong" with having multiple patterns like this in a single application, especially during a refactoring exercise. I would strongly suggest documenting the patterns that you are changing from and to and the reason for the modification so that future developers understand what is happening.

I would make one substantial modification to your proposed implementation, however: define Enrol at the Student level as an Overridable method. 

If there is no default implementation for all students, change Overridable to MustOverride. This will in turn force Student to be declared as MustInherit, but this is ok if you can only call Enrol on instances of Undergraduate or Graduate.